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

1 ：ナイコンさん：2021/03/16(火) 23:44:11.88 .net

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


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

■過去スレ
8086 vs. Z80 vs. 6809 vs. 6502　その13 [無断転載禁止]©2ch.net
https://matsuri.5ch.net/test/read.cgi/i4004/1474548959/

8086 vs. Z80 vs. 6809 vs. 6502　その12 [無断転載禁止]©2ch.net
http://hanabi.2ch.net/test/read.cgi/i4004/1468637057/l50
8086 vs. Z80 vs. 6809 vs. 6502　その11 [無断転載禁止]c2ch.net
http://hanabi.2ch.net/test/read.cgi/i4004/1462424764/
8086 vs. Z80 vs. 6809 vs. 6502　その10
http://hanabi.2ch.net/test/read.cgi/i4004/1407651926/
8086 vs. Z80 vs. 6809 vs. 6502　その9 (再び)
http://hello.2ch.net/test/read.cgi/i4004/1365951318/
8086 vs. Z80 vs. 6809 vs. 6502　その9 (短命)
http://ikura.2ch.net/test/read.cgi/i4004/1362833400/
8086 vs. Z80 vs. 6809 vs. 6502　その8
http://ikura.2ch.net/test/read.cgi/i4004/1333965297/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2 ：ナイコンさん：2021/03/16(火) 23:50:31.05 .net

■過去スレ
8086 vs. Z80 vs. 6809 vs. 6502　その7
http://ikura.2ch.net/test/read.cgi/i4004/1319314159/
8086 vs. Z80 vs. 6809 vs. 6502　その6
http://toki.2ch.net/test/read.cgi/i4004/1286766300/
8086 vs. Z80 vs. 6809 vs. 6502　その5
http://toki.2ch.net/test/read.cgi/i4004/1280380374/
8086 vs. Z80 vs. 6809 vs. 6502　その4
http://gimpo.2ch.net/test/read.cgi/i4004/1252639237/
8086 vs. Z80 vs. 6809 vs. 6502　その3
http://gimpo.2ch.net/test/read.cgi/i4004/1235851359/
8086 vs. Z80 vs. 6809 vs. 6502　その2
http://gimpo.2ch.net/test/read.cgi/i4004/1213527504/
8086 vs. Z80 vs. 6809 vs. 6502
http://bubble6.2ch.net/test/read.cgi/i4004/1165801265/
6809とZ80 part 2
http://bubble4.2ch.net/test/read.cgi/i4004/1093190685/
6809とZ80
http://bubble2.2ch.net/test/read.cgi/i4004/1008496410/

3 ：ナイコンさん：2021/03/17(水) 09:57:25.33 .net

前スレの荒らしが逃亡したので、保守と予防を兼ねて簡単に経緯を書くと

前スレで(ﾜｯﾁｮｲ 857d-O+UI)の初出は
https://matsuri.5ch.net/test/read.cgi/i4004/1474548959/926-927
だが、上の内容は前スレを遡っても電卓の話など出ていない

ではどこで出ているかと言うと、このスレ
https://matsuri.5ch.net/test/read.cgi/i4004/1577484641/

話を戻して、前スレで間接的に関係のある書き込みはと言うと
https://matsuri.5ch.net/test/read.cgi/i4004/1474548959/888
だが、ここには「Appleがパソコンを発明した」と書かれているが、「初代IBMPC」とは
全く書かれていない
（当然だが前スレの>>888書き込みをしたのは自分ではない）


しかし、前スレの最後では「初代IBMPCがAppleの影響を受けていた」と言う結論を書いて
勝手に勝利宣言した

と言う経緯になっている
尚(ﾜｯﾁｮｲ 857d-O+UI)と共犯者は、この間一度もCPUの話はしていない

尚、現在はまたもとのスレに帰ったようだが
https://matsuri.5ch.net/test/read.cgi/i4004/1577484641/55
上記の通り(ﾜｯﾁｮｲ 857d-O+UI)が上のスレの住人だった事は容易に説明がつく

4 ：ナイコンさん：2021/03/17(水) 11:46:28.77 .net

ご立派な粘着dbpっ子ですなあ。悲惨w

5 ：ナイコンさん：2021/03/17(水) 11:48:04.40 .net

dbp bpd

6 ：ナイコンさん：2021/03/18(木) 07:02:53.64 .net

PC-100の回路設計者である松本吉彦さんは1976年のトランジスタ技術誌に
MC6800を用いた自作マイコン基板の記事を連載していた偉人だったから
68000という選択が彼において順位1位の候補であっても不思議じゃないだろう。

しかしマイクロソフトのバイスプレジデント格の西和彦氏からすれば、CPUが
インテル系8086/8088出なければならない。というは絶対条件だったに違いない。

後のI/O誌＠工学社の星氏は76年当時のCQ出版の編集者。彼の手下が西郡司塚本。
1976年の電子技術関連メディアで松本吉彦さんの影響力は計り知れないほど
大きかった。青空文庫の冨田 倫生さんが「日本のウォズニアク」と評していたが
エバンジェリストとしてはウォズ以上の影響力だったと思うね。
-------------
926ナイコンさん2020/09/30(水) 03:03:56.83
>>951
松本さんといえば、1976年にトランジスタ技術誌で連載された
モトローラ6800を応用したマイコン基板製作記事。連載期間は
第1回、1976年8月号、p186〜200
第2回、1976年9月号、p201〜216
第3回、1976年10月号、p200〜216
第4回、1976年11月号、p201〜216
第5回、1976年12月号、p194〜215
第6回、1977年1月号、p201〜216
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1361216268
記事内容は翌年1977年のムック誌で再録されているようです。入手困難ですが。

私だけのマイコン設計&製作 : マイコンピュータ・プランニングA〜Z
松本吉彦著　　（つくるシリーズ, 5）　CQ出版, 1977.12

7 ：ナイコンさん：2021/03/18(木) 07:03:27.29 .net

誤爆すまんね。

8 ：ナイコンさん：2021/03/18(木) 07:36:15.57 .net

前スレでマカーにIBM-PCのどの仕様がApple IIの影響を強く受けていたか聞いたところ以下のソースをいただきました。

> https://books.google.com/books?id=Pq3POofPsBEC
> の33ページから始まる"Ostracized PC1 Designer Still Ruminates 'Why?'"って記事を読んでみな

英文3ページ弱のボリュームです。ですが結論をいいますと、そういった記述はございませんでした。
マカーはやっぱりマカーです。

9 ：ナイコンさん：2021/03/18(木) 08:24:53.91 .net

>>8
マカーと民主党員を同一視するのはNG

10 ：ナイコンさん：2021/03/18(木) 11:09:37.87 .net

>>990

> ttps://books.google.com/books?id=Pq3POofPsBEC
> の33ページから始まる"Ostracized PC1 Designer Still Ruminates 'Why?'"って記事を読んでみな

面白いね。Eggebrecht 氏はPC開発のまとめ役だ。ただし
PC開発はチーム全体によるもの開発チームメンバーは全員がApple][を所有していた。
Apple2の操作のfeelingはIBM製品にはないと認めざるを得なかった。そういう意味で
70年代末80年代初頭のパソコン業界のリーダーはAppleでIBMはフォロワー追従者。
そしてウォズ＠Appleへの回答がIBM PC(5150)だった。というニュアンスみたいね。

11 ：ナイコンさん：2021/03/18(木) 12:11:12.37 .net

>>8
なるほど、デマカー

12 ：ナイコンさん：2021/03/18(木) 17:46:23.74 .net

PC MAGAZINE 9月号、P33〜 "Ostracized PC1 Designer Still Ruminates 'Why?'"　の記事まとめ

・IBMから追放されたlewis C. Eggerechtの記事。
・彼は開発チームのchief architectとしてIBM-PC(1981リリース)を開発した。
・1982年初めに、PCの本を書き始めた。Bridge Technologyという会社を立ち上げた。
・PCの知識を活かして他社に営業かけたら1982年9月に産業スパイで訴えられIBMをクビになった。
・転職先(Franklin Computer)がAppleに訴えられ、また無職になった。
・なぜ？　おれには理解できない。著作権はクソ。

13 ：ナイコンさん：2021/03/18(木) 17:52:10.37 .net

記事 まとめ2
・元々はマイコンオタクで一番スゲーと思ったのは、モジュール方式のS100インターフェース。
・5100とIBM-PCは別系譜。5100はIBMテクノロジーが使われた。
・System/23 Datamasterの開発に関わった後、IBM-PCの開発をした。←回路構成はこれを流用か
・開発指示は"piece together"　←最初から既成部品で組み立てろだった？
・最初のワイヤーラップ機は1ヶ月かからなかった。最終機と初号機は同じだった。
・開発期間の多くはベンダーとの交渉だった。判明した設計上の問題のほとんどは納期によって決定した。

14 ：ナイコンさん：2021/03/18(木) 17:57:45.04 .net

記事 まとめ2
・この分野はAppleがリーダーと感じていたので、それに倣ってIBM-PCをオープンにするようIBMを説得した。
・開発メンバーはみなAppleIIを持っている。←この文脈がよく分からない。スタバやマクドナルドで必要もないのにMacを使い出してアピールする感じ？ IBM-PCの仕様がAppleIIの影響受けた根拠はこれだけ？
・PCjrは優れている。商業的失敗はIBMの宣伝ミス。←PCjrの開発も関わった？
・IBMは顧客の移行戦略がなってない。

以上です。

15 ：ナイコンさん：2021/03/18(木) 21:15:27.10 .net

>>14
IBM PCへのApple IIの影響で重視されているのは
オープンにしたというところ

IBM PCはある意味世界を制覇したわけだけど
その要因の一つがオープンだった点だと考えられているからね

16 ：ナイコンさん：2021/03/18(木) 22:09:14.57 .net

普及させたいが資本or予算がなく、他社の周辺機器メーカー、ソフトハウスに協力してもらいたい　→オープンにする
普及してマーケットリーダーになったので、自社の関連商品で儲けてる奴の利益も自分のものにしたい　→クローズにする

単純な経営学の話にすぎない

17 ：ナイコンさん：2021/03/18(木) 22:22:17.82 .net

>>14
エッゲブレヒトさんの最近の経歴は以下。現在73。IBM-PCのアーキテクトだった頃
PCに関する特許を6件取得したそうだ。フランクリンといえばApple][のコンパチ機を
出して訴訟喰らってアポーんした悪名高き会社だね。エッゲさんは自身Apple2ユーザー。
パソのハードソフトの仕様機能の上澄みの蒸留エッセンスが使用感。つまり
ルック＆フィール。ユーザであるということは良さも欠点も知り尽くす基本的な
経験態度でap2をユーザとして知り尽くしていた。ということでしょうね。

Lewis C Evgebrecht
https://www.macroaxis.com/invest/manager/AVGO--Lewis-Eggebrecht

18 ：ナイコンさん：2021/03/18(木) 23:00:10.97 .net

>>16
実際の設計者の話が間違いというなら論拠を示してね
今までの定説を覆す資料があるならそれはそれで大発見

19 ：ナイコンさん：2021/03/18(木) 23:26:20.16 .net

> Close-mouthed
> the story of the making of the IBM PC may never be told.

どの話だろう。彼は何も話してない。
マカーがなぜ捏造ばかりするのか。妄想と現実の区別がつかないのだ。

20 ：ナイコンさん：2021/03/18(木) 23:41:46.79 .net

今までのマカーの定説は何一つ資料が見つかってない。見つかればほんとそれは大発見。

パソコンはジョブスが発明した。
フロッピーディスクはジョブスが発明した。
GUIはジョブスが発明した。
マウスはジョブスが発明した。
インターネットはジョブスが発明した。
MP3プレイヤーはジョブスが発明した。
スマホはジョブスが発明した。

21 ：ナイコンさん：2021/03/19(金) 01:02:35.08 .net

不可触ダウンズ土左衛門か。触るなよw

22 ：ナイコンさん：2021/03/19(金) 01:10:04.67 .net

IBM-PC開発者が語っている!!!　これがIBM-PCがAppleIIの影響を強く受けた記事だ!!
→　一言もそんなこと言ってませんでした

40年経ってもマカーはマカーだなぁ。

23 ：ナイコンさん：2021/03/19(金) 05:37:35.35 .net

>>18
単にこの仕様がAppleIIの影響で、この記事の◯ページの何行目に開発者が述べてますで終わりの話だよな。

それを一切質問には答えず、数ページの英文を読めと突きつけて
読んでみたらどこにも書いてないって、ちょっとリアルで頭おかしいじゃないの？
しかもどこにも書いてないよと指摘された後に、実際の設計者の話だ!!とかリアル池沼だよ。

24 ：ナイコンさん：2021/03/19(金) 07:31:36.58 .net

>>14に書いてあるじゃん

25 ：ナイコンさん：2021/03/19(金) 08:01:47.79 .net

>>24
>>14　はおれがまとめたものだけど、そんなことは書いてないよ。人のレス使って嘘つかないでくれる？

26 ：ナイコンさん：2021/03/19(金) 10:33:11.77 .net

実際はオープンにして消えた企業のほうが多いわけだからオープンを成功の理由にするのは違うな。
当時IT業界トップのIBMがオープンにしたのだから意味があった。逆にIBMが落ちぶれてから、
オープンのLinuxに投資したが結局クローズドのWindowsサーバには勝てなかった。

27 ：ナイコンさん：2021/03/19(金) 11:08:10.76 .net

>>26
スパコンのOSはほぼ100％犬x。AWS、GCPazureとかクラウドインフラ系も犬x。
携帯世界は犬x直系の泥携帯が世界制覇してWindows phoneは消滅ーゲイツも泥携帯。
だいたいがWindows本体OS内部にも犬ソースが大量に侵食しているし。
Windowsって最後skinだけになるかもね。NT鯖ってどこで生き延びているの？

28 ：ナイコンさん：2021/03/19(金) 11:13:59.48 .net

犬xにも問題はある。ソースオープンで鍛えられた信頼性という果実を
中国北朝鮮がミサイルロケットや核開発でホルホルしちゃっている件。

29 ：ナイコンさん：2021/03/19(金) 14:51:04.37 .net

英語の記事でも書かれているように、IBM-PCはS100バスマシンの構造と市場を乗っ取る製品だったわけで
なにがなんでもApple様を見習って真似して作った事にしたがるキチガイは本当に死んでいなくなって欲しいわ

30 ：ナイコンさん：2021/03/19(金) 18:16:11.75 .net

>>27
ADドメインサーバ
Azure

31 ：ナイコンさん：2021/03/19(金) 21:42:55.42 .net

S100バスに感銘を受け、AppleIIを保持し、PCjrの拡張性を擁護。
つまり、ガチャコンってカード指して機能up、パワーアップという自作PC的なワクワク感に魅了されたマイコンオタク。
マイコンオタクにとって仕様がオープンのほうが自由度があっていいのは当たり前で、
閉鎖的なIBMでオープン仕様にするには、8bit機界のリーダーであるAppleは既にそうしているからと説得するのが一番いい材料。

それがなぜ、IBM-PCの仕様だのルークアンドフィールだのがAppleIIの影響を受けたと彼が語ったという話になるのか。

32 ：ナイコンさん：2021/03/19(金) 22:17:31.39 .net

>>27
逆だよ。MSはゲイツやバルマーがいなくなって、
オープン化に舵を切ってからWindowsはどんどん落ち目になったんだよ。

33 ：ナイコンさん：2021/03/20(土) 00:41:58.97 .net

周回遅れだが・・・
>>1 おつ

34 ：ナイコンさん：2021/03/20(土) 01:14:13.15 .net

ところでスレタイ・・・・・

そういや秋月でわりと最近6502互換売り始めてて驚いた。地味に息長いな

８ビットマイコン　Ｗ６５Ｃ０２Ｓ６ＴＰＧ−１４
お客様からのご要望を頂き販売開始いたしました。
https://akizukidenshi.com/catalog/g/gI-15324/

35 ：ナイコンさん：2021/03/20(土) 01:38:32.33 .net

回路の小ささが一番の武器だからこれからもIPコアとして使われるだろうけど、DIPの需要ねぇ。
まさかこの板のApple信者がいたずらで要望出してないだろうな。

36 ：ナイコンさん：2021/03/20(土) 18:52:42.71 .net

Apple IIをブレッドボードで作ろう

37 ：ナイコンさん：2021/03/20(土) 19:32:17.78 .net

メカニカルキーボードで有名なFILCOのコントローラが6502コアだった。
WEBで資料探したがMEGAWINという会社のMPC2F35らしい。

FICOのZERO（ばらした）とMajestouch2（分解前だけど多分そう）にのってる石。

38 ：ナイコンさん：2021/03/20(土) 19:39:12.69 .net

・・・で思ったのは、8086系は魔改造繰り返して今やcore iだしZ80，6502も他社含めて互換IC展開してるのに6809系だけが見つからない(´・ω・`)

39 ：ナイコンさん：2021/03/20(土) 21:51:06.28 .net

youtubeで初代IBM-PCの実機見ると結構速いな。こりゃ8080CP/M機を瞬殺するわな。
アセンブラのソフト資産も移行しすいしCP/Mユーザーの移行先としてベストの選択だったのだろう。

40 ：ナイコンさん：2021/03/21(日) 03:41:10.59 .net

>>38
ヒント: ソフト資産

マイクロソフトの6809Basicインタプリタと、OS/9しかなかっただろう

41 ：ナイコンさん：2021/03/21(日) 05:27:56.04 .net

>>17
エッゲブレヒトさん。調べてみると色々事績が出てくる。主にビデオ周り。
IBM時代は仕様決定権をもってPCの文字セット(CCSID437)を決めている。
次がフランクリン社でApple][互換機開発。CD立ち上がり時期はフィリプスで
マルチメディア機器開発のチーフエンジニア。90年代初頭はcommodoreの
技術担当副社長。CD32とかA1200のAGAとか。92年トロントで開かれた
イベントでキーノートスピーチ。その次がS3でビデオカード開発。
以後SI系のICSを経て直近はブロードコム。Commodore時代はAmigaユーザー
に宣託を伝える希望の星だったみたい。

IBM時代について本人は口を閉ざして語りたがらない件は、察するに彼が
PC開発後に書いて出版されたインタフェーシングの書籍が、技術公開を嫌う
上層部と揉め事の火種になったからみたいね。PCの機能拡張とかか周辺制御に
ついて、読者はバイブル扱い高評価されたみたいだが。IBMの飯の種を棄損した印象。

Interfacing to the IBM Personal Computer
https://archive.org/details/interfacingtoibm00egge

42 ：ナイコンさん：2021/03/21(日) 06:23:18.95 .net

>>31
41頁中央にあるfeelingという語のニュアンス空気をどう読むか。ということです。

76-77年ごろs100機の実物を見て触れたことが何度かある。1番気になったのは
CPU基板とかメモリ基板それぞれにヒートシンクをねじ止めして三端子レギュレータを
取り付けていたこと。電源がトランス整流式でバカでかいケミコンで平滑化。
あれでは負荷時の過渡特性心許ないという印象でそっ閉じバイバイ。バス仕様を
見ると電源は18v-8v-(-6v)で基板ローカルで定電圧制御を要求する仕様。また
アドレスバスとか順序ぐちゃぐちゃ。非対称杉で美しくない。

類似の感想批判は70年代からあり、市販基板類もガレージ粗製が多くノイズ耐性悪く
相性問題甚だしくトラブル多発。実はトーシロー向きではないのね。当のs100製品
メーカー自身、非力ゆえの先細りをよく知っていし、77-78年のApple,commodore,
Tandy,Atariのパソコン市場参入で1979年ごろにはs100機製造な主要メーカーaltair(mits)、
IMSAI、TDL、ProcessorTechとか主要大半が倒産あるいは売却撤退で消滅していた。
s100機の市場って1,979年には整地済みだったですね。
Altairの創業者のエドさんは本業のお医者さんに復帰。SOL-20のフェルゼンシュタイン氏は
その後ライターのオズボーン氏と組んで1枚基板なCP/M機で大ヒット飛ばすも次が出せず。

s100
https://www.retrotechnology.com/herbs_stuff/s100bus.html

80年代に入ってなお生き残っていたのはcromemco(旭硝子)とnorth hrizon(工人舎=SOTEC)
くらい。BYTE誌のコラム「混沌の館」で作家ジェリー・パーネル氏は意地で2台使いでレポ
続けていたのはご立派だったですが、昔は昔。

43 ：ナイコンさん：2021/03/21(日) 07:31:13.57 .net

Off the Shelf　章のタイトル。　既成部品使うとリスク減る〜みたいな話
Open architecture　〜　パラグラフはオープンアーキテクチャの話〜　IBMはクローズドだ〜みたいな話
で、彼が言います。
“The feeling was that IBM was not a leader in this area, Apple was the leader.
Apple had an open architecture, so we followed suit,” he says.

↓で、彼が言ったことはこう解釈するらしいです。
私達はAppleのルック＆フィールに追従した。IBM-PCの仕様はAppleIIの影響を強く受けた。

ついていけません。

44 ：ナイコンさん：2021/03/21(日) 08:07:21.45 .net

現実のIBM-PCのルックアンドフィール
見た目　ごつくて、でかい箱にFDドライブつけただけのデザイン。
操作感　クローズドのMSのDOS。普通にCP/Mのパクリ。

45 ：ナイコンさん：2021/03/21(日) 10:23:54.16 .net

もうCP/Mはジョブスが発明したって言い出しそうだな。

46 ：ナイコンさん：2021/03/21(日) 21:41:21.50 .net

面倒なオカルト三起源説
Apple起源説
RISC起源説
半島起源説

47 ：ナイコンさん：2021/03/23(火) 18:46:38.46 .net

AppleIIもゲームしかしないライトユーザーはともかく、
プログラム書く人は結局、MSのZ80カード指してCP/M使ってたというオチ。

48 ：ナイコンさん：2021/03/23(火) 21:55:06.40 .net

80カラムカードも忘れるな

49 ：ナイコンさん：2021/03/24(水) 05:14:29.88 .net

AppleIIのCP/Mユーザが16bitマシンの移行先は現実的にPC互換機+DOSしかなかった。
これはApple信仰への裏切りであった。しかし、PC互換機がAppleIIからの流れのマシンとなれば話は別だ。
彼らは信者から非難されないためにそう吹聴したのだろう。

50 ：ナイコンさん：2021/03/24(水) 20:20:13.18 .net

>>47
さみしい事いうなよ、スレタイ的にさ。
環境込みで Z-80 >>6502 ってi言いたいの？ 違うでしょ

51 ：ナイコンさん：2021/03/24(水) 20:32:42.95 .net

6502のバイナリ作成って基本CP/MorDOSその他でクロス開発と思ってたけど。
開発環境構築するには面倒な6502。

52 ：ナイコンさん：2021/03/25(木) 04:22:33.31 .net

ProDOSでエディタアセンブラデバッガさ

53 ：ナイコンさん：2021/03/25(木) 05:49:44.11 .net

VisiCalcはマサチューセッツ工科大学が時間貸ししてたMulticsのアセンブラで開発したらしい
ascii.jpの記事に書かれてるね
アメリカでは時間貸しのコンピュータ上で開発したという例がよく出てくるね
Microsoftも大学などの時間貸しのPDP-10でクロス開発してたようだし
のちにDECSYSTEM-10かDECSYSTEM-20か忘れたが社内に導入したらしいし
もう、この世を去ったビルゲイツの相棒のポールアレンは
PDP-10の互換機の実働品を個人で所有してたらしいぞ

54 ：ナイコンさん：2021/03/25(木) 08:51:23.93 .net

そりゃまあ、マイコン上で動くアセンブラとかよりメモリも豊富だし、何より速度速いもんな

55 ：ナイコンさん：2021/03/25(木) 09:22:35.45 .net

ROMモニタに逐行ASMと逆アッセ内蔵されていたよね。
俺はマーリン使ってた。

56 ：ナイコンさん：2021/03/25(木) 09:48:04.26 .net

6502使ってるパソコンはコモドールもアタリもZ80付けてCP/M動かせるの当たり前だしな
あの、開発環境含むビジネスアプリはCP/M前提ってノリは、
日本のZ80なのにCP/M前提では無いってのと大違いすぎ
フロッピーディスクコントローラーに乗ってるZ80でCP/M動かしたりしてて、
今の感覚のOSとは違いすぎるが

57 ：ナイコンさん：2021/03/25(木) 12:52:14.65 .net

ソニーがSMC-70でCP/Mを採用しても評価されなかったりしてて、
漢字使えないのにビジネスアプリなんて意味ない扱いだったって事だな
当時はそれ以前に日本でビジネスアプリがパーソナルで使われる事は無い扱いだったが98では成功したのからすると漢字の問題

98でも最初はオプションだったほど漢字ROMが高すぎたが、
のちのPDA用では8x8dot漢字FONTが作られたほどで、割り切ればそこまで大容量ROMじゃなくても漢字は使える
8x12dot漢字FONTならコスパ良く受け入れられる字形を確保できる
4KBROM×9個な36KB分くらいか

後々Z80でもX1turboで漢字テキストVRAM使えば実用的な漢字表示ができてた
欧州では8bit拡張アルファベットではなく7bitアルファベット合成文字がまだ使われてた
ってな状況からすると、半角8bit全角16bitにこだわる必要はなく、
全部同じ寸法な文字でISO-2022-JP的なテキストデータ使用でのCP/M機が成り立てる時代だったはず
MDA720x350ではなく720x208での80桁16行漢字表示
専用モニターなら720x416での80桁32行漢字表示なCP/M機を1981年くらいには出せてたはずな技術水準だったのか

58 ：ナイコンさん：2021/03/25(木) 22:22:48.19 .net

CP/MマシンならEPSONのQC-10の話も聞きたいなぁ

59 ：ナイコンさん：2021/03/26(金) 02:24:27.96 .net

漢字テキストVRAMと日本語DOSとデバイスドライバ型かな漢字変換フロントエンドプロセッサが成功の秘訣

60 ：ナイコンさん：2021/03/26(金) 05:00:38.51 .net

8bit cm/mは産廃ゴミ。msx-dosが救済したが。

61 ：ナイコンさん：2021/03/26(金) 16:59:15.39 .net

日本の8bit機はせいぜいJIS第二水準漢字ROMまでで、
辞書ROM、漢字テキストVRAMは負け組ハードの機種。

CP/Mの普及とは関係ないですね。

62 ：ナイコンさん：2021/03/26(金) 18:34:55.31 .net

X1turbo
あたりは、負け組というほどマイナーじゃない
マイナーというのはMZ-2500とかだな
漢字ROMに漢字テキストVRAMに辞書ROMまであったはず、辞書ROMは別売りだったと思うけど。

63 ：ナイコンさん：2021/03/26(金) 18:53:33.92 .net

PC互換機が日本で売れなかったのは漢字表示が98に遠く及ばなかったからだけど、
CP/Mが売れなかったのは日本語表示能力ではなく、
単に高価で且つゲーム目的ばかりの8bitユーザーに必要なかったからだろうな。

64 ：ナイコンさん：2021/03/26(金) 19:24:58.53 .net

その頃の貧乏青少年は、だだのBASICやマシン語モニタ（S-OS SWORD）やっていてな （涙；

65 ：ナイコンさん：2021/03/26(金) 19:30:23.49 .net

当時のハードじゃCP/M劇重だったじゃん

PC-8801mkIIでWordStarとか使ってみたけど
半角英語の編集ですら重すぎて重すぎて

66 ：ナイコンさん：2021/03/26(金) 19:38:04.26 .net

"ma"が足りなかったんだよきっとｗ

67 ：ナイコンさん：2021/03/26(金) 19:38:17.80 .net

マイコン世代とパソコン世代(ゲーム目的。主に団塊Jr以降)とは人種が違って微妙に話が噛み合わない。

68 ：ナイコンさん：2021/03/26(金) 19:48:20.49 .net

いまやハム親父(結構な歳の無線愛好家)相手に、MS-DOS（PC-DOS2000）の話題振って可笑しがられる時代なんで、
この板的には誤差なんじゃないかと・・・・（＠希望的観測

69 ：ナイコンさん：2021/03/26(金) 19:57:43.83 .net

そもそもCP/Mの広告見たことないなぁ。8bit機の広告もグラフィックとかハードとBASIC自慢ばかり。
メーカーもCP/Mなしで使う前提の広告。DOS前提の16bit機の広告とは明らかに違う。

70 ：ナイコンさん：2021/03/26(金) 20:02:08.27 .net

俺が知る8bit機の開発者の半数アマ無局免保有経験者だったけどね。
打ち合わせでアレなジャブ入れると打ち返してきて盛り上がったな。
某T社とかのマネージャーには真空管/TR名機のVFO設計者とかも。

71 ：ナイコンさん：2021/03/26(金) 20:05:28.41 .net

無線でパケット通信してたんですね。どっちかというとキモいBBSばかりでしたよね。

72 ：ナイコンさん：2021/03/27(土) 05:09:41.68 .net

TNCのパケット通信の面白さに気づかなかったよ当時若過ぎた

73 ：ナイコンさん：2021/03/27(土) 07:09:46.57 .net

富士通FMシリーズCMのイメージキャラクタ演じていたタモリは60年代初頭
高校の無線クラブで活動。送信機が終段真空管807のトリオTX88A。ブラタモリの
秋葉原神田編でラジオセンターのじゃんくやで807見つけてウンチクしてましたね。
RBBSは85年〜でしょ。TK-80/8001の開発を主導していた日電w氏はマイコン販
以前の10年間某K社で業務用無線機の設計開発者だったとか。

74 ：ナイコンさん：2021/03/27(土) 07:31:12.61 .net

これがマイコン世代です。

75 ：ナイコンさん：2021/03/27(土) 09:47:59.82 .net

>>65
そうか？
PC-8001のCP/MでWordStar使ってたけど遅いとか思ったことない
FDDだったからロード/セーブはそこそこ時間が掛かったような思い出があるけど

76 ：ナイコンさん：2021/03/27(土) 19:02:36.91 .net

X1のCP/MでWoremaster初めて触った時重く感じたな。

比較対象がBASIC+マシン語環境（一般ピーポにゃこれしかなかったよね）だったから。
画面表示はべったりハード依存だし、基本オンメモリでFDDはほとんど回さないし体感速度は良かった。

77 ：ナイコンさん：2021/03/27(土) 22:47:46.86 .net

PC-8001ってDMA割り込みで実質1.8MHz程度とかwikipにあるけど、8bit機としては相当遅い部類でしょう。
そもそもテープ全盛期にFDD追加してるってどんだけ金持ち。

78 ：ナイコンさん：2021/03/27(土) 23:11:14.21 .net

オプション品としては用意されてたけど、つけてる人はごく一部じゃね?
フロッピー用のインターフェースすら、初代の8001にはついてないぞ
8001mark2やSR,、8801初代にはフロッピーのインターフェースついてたけど、フロッピーのドライブを搭載したモデルが出たのは8801mask2からだろ

80年代初期には5インチフロッピのドライブですら三十万近くじゃなかったっけ

79 ：ナイコンさん：2021/03/27(土) 23:34:56.56 .net

>>77
> そもそもテープ全盛期にFDD追加してるってどんだけ金持ち。
さすがに個人じゃなくて大学の研究室で使ってた
当然8inchでガッコンガッコンの時代w

80 ：ナイコンさん：2021/03/28(日) 09:18:12.45 .net

旧・丹青通商らしき店でZ80まだ売ってる。写真が美麗でﾜﾛﾀ。
https://page.auctions.yahoo.co.jp/jp/auction/v587690641

でも6809,6502はなかった(´・ω・｀)

81 ：ナイコンさん：2021/03/28(日) 11:18:00.39 .net

6502は秋月で互換品を売ってる

82 ：ナイコンさん：2021/03/28(日) 11:25:05.10 .net

>>80
すでにザイログもないし、現存のZ80って他社製の互換CPUだけだよな?

それならば、6502の互換チップの方が、古くから6502互換チップ作ってきたとこの製品だし、むしろよく残ってる部類かも

83 ：ナイコンさん：2021/03/28(日) 11:28:23.54 .net

>>79
その辺のなら、たしかMZにも純正フロッピードライブがラインナップされてはいたな
MZ-80Bの頃に取り寄せたカタログに、三十万ほどの値段で載ってた
インターフェースボードを取り付けるための拡張スロットすら別売りだったかも?
ただ、8001も初代機の拡張スロットは別売りだったのではなかったかなあ

84 ：ナイコンさん：2021/03/28(日) 11:34:56.02 .net

>>78
8031が31万円ーそのほかに8011か8012か8033とかのインタフェース必須。
周辺機器リスト
https://retrocomputerpeople.web.fc2.com/NEC/List8000.html

85 ：ナイコンさん：2021/03/28(日) 14:18:20.22 .net

>>82
https://www.zilog.com/
買収はされたけど会社はまだあるし互換品だけどちゃんと作ってるよ

86 ：ナイコンさん：2021/03/28(日) 19:56:55.22 .net

FDDだから時間かかった？　大学の研究室なんてまだパンチカード、紙テープの時代だろ。

87 ：ナイコンさん：2021/03/28(日) 21:05:23.62 .net

元々CP/Mは8インチ用に作られてたから、5インチでは無駄に遅くなってる不都合でも有ったのか？
セクタ数など固定要素に最適化してるとかの

88 ：ナイコンさん：2021/03/28(日) 22:02:03.75 .net

>>86
それ全部使ってたよ…
汎用機 … パンチカード
ミニコン … 紙テープ
マイコン … FDD
の時代

>>87
いや使ってたのは8inchだけどシークも遅いしヘッドロードも遅いよ
5inchの方がシークとかは速い

89 ：ナイコンさん：2021/03/29(月) 07:40:54.02 .net

>>87
FDDとFDC@CPUの接続方式の違いがアクセス速度を左右していた。
特に8255パラレルハンドシェイクな8031系とか低速シリアル接続の
1541@c64とかは遅速組。

90 ：ナイコンさん：2021/03/29(月) 07:56:08.67 .net

専用のFDC使ってるのでも、ドライブがわの対応する転送レートにランクがなかったっけ?

後期のドライブは500kbpsぐらいだけど、初期のは125kbpsぐらいだろ?

91 ：ナイコンさん：2021/03/29(月) 08:05:54.02 .net

FDDとFDC@CPU直結設計の場合は8257なDMAが使えた。高速組。

CP/MのFDDドライバーは機種ごとに記述されるべきBIOSファイル。
セクタサイズは128バイト基準。137/256/512倍とセクターなFDDでは
ブロッキング＆デブロッキングアルゴリズムを実装必須。ここが当時の
PGの難所。他に速度速度チューニングのためのスキュー設定。
5インチ系FDはセクタ数＠トラックや飛越飛ばしスキュー設定値が無統一
故に機種間互換性がほぼ無し。対してMS-DOSは統一済み。FD互換性有りで優位
ウィキペとか詳しい資料数多あるね。

92 ：ナイコンさん：2021/03/29(月) 08:10:15.20 .net

倍と　バイト

スキュー設定はDOSのst-506なHDD時代はフォオーマット時に変更可能だった。
diskstarといったフォーマッタでスキュー値いじってあそんでいたな。

93 ：ナイコンさん：2021/03/29(月) 08:46:28.30 .net

>>90
そうだね。元祖シュガートSA-400の単密が125kbit/s
NEC 1155倍密が500kbit/s 単密は250kbit/sらしい。
他にデータセパレータの有無とか。

94 ：ナイコンさん：2021/03/29(月) 08:50:38.68 .net

スキュー？
インターリーブのことか？

95 ：ナイコンさん：2021/03/29(月) 10:32:20.49 .net

スキューはスキュー、インターリーブはインターリーブでは？

96 ：ナイコンさん：2021/03/29(月) 10:55:22.86 .net

>>95
別の概念なの？
ならFDでスキュー設定なんて聞いたことないけど…

97 ：ナイコンさん：2021/03/29(月) 11:40:27.29 .net

スキューはセクタ配置全体を（インデックス位置から）ずらすこと
インターリーブは連続セクタをディスク上の何セクタかおきに配置すること
なので違う
ディスク回転に転送設定が間に合わなくならないようにするためって点では同じだけど

98 ：ナイコンさん：2021/03/29(月) 11:53:04.81 .net

CP/Mが現役だった頃はスキューという語は後世のインターリーブとほぼ同義。
2.2の英文マニュアルでskewは10数回登場するがinter云々は出現無しだね。
オリジナルのcp\mディスクのスキューファクタは6で設定されているそうだ。

Standard CP/M systems are shipped with a skew factor of 6,
where six physical sectors are skipped between each logical read operation
@215page
http://www.cpm.z80.de/manuals/cpm22-m.pdf

Sector Skewing
https://www.seasip.info/Cpm/skew.html
https://www.seasip.info/Cpm/formats.html

インターリーブという語は「新語」？

99 ：ナイコンさん：2021/03/29(月) 12:26:21.02 .net

前のトラックの最終セクタから次のトラックにシークしてすぐ先頭セクタにアクセスできるように、トラックごとに先頭セクタをずらしてフォーマットする方法があった気がする

100 ：ナイコンさん：2021/03/29(月) 12:43:23.34 .net

>>99
それがスキュー

101 ：ナイコンさん：2021/03/29(月) 18:54:44.21 .net

こういう話ができる老人ホームに入りたい

102 ：ナイコンさん：2021/03/30(火) 01:25:47.89 .net

老人ホーム入ったらお終いだぞ

103 ：ナイコンさん：2021/03/30(火) 04:52:38.96 .net

ひたすらマカー老人の捏造話を繰り返し聞くことになるな。

104 ：ナイコンさん：2021/03/30(火) 05:27:05.81 .net

こんな老人ホーム嫌だ！

マカーマカーってぶつぶつ言ってる老害ばかりの老人ホーム

105 ：ナイコンさん：2021/03/30(火) 05:42:32.22 .net

ヤフオクでえらい高価なボード見つけた。まだ4日あるのに2万越えとか
https://page.auctions.yahoo.co.jp/jp/auction/b546014601

・・・・スレ的には新しすぎるか。

106 ：ナイコンさん：2021/03/30(火) 09:37:34.87 .net

これもどうぞ
https://page.auctions.yahoo.co.jp/jp/auction/o465131429

107 ：ナイコンさん：2021/03/30(火) 12:29:54.08 .net

pc-8801用の16ピットカードか
ということは、8088とメモリが載ってるのかな?

108 ：ナイコンさん：2021/03/30(火) 12:40:47.35 .net

>>107
8MHzのμPD8086(i8086互換品) と128KBのRAMを積んでる
初代PC-9801より速いな

109 ：ナイコンさん：2021/03/30(火) 12:48:44.16 .net

当時の思い出話してる人の
https://www.google.co.jp/amp/s/gamp.ameblo.jp/kagra/entry-10712529954.html

MS-DOS上でのクロス開発とか考えると悪くない
何で当時にもっと盛り上がらなかったのだろう

110 ：105：2021/03/30(火) 20:01:06.01 .net

アスキーR800(Z80互換)はスレチだったか。うん、わかってた(´・ω・｀)ｼｮﾎﾞｰﾝ

111 ：ナイコンさん：2021/03/30(火) 20:43:37.32 .net

>>110
スレチじゃなかろう。PLUS-80はZ80A, Z80B, Z80Hバージョンが出ていたことは知っていたが
R800版があったとは知らなかった。オクの件、制御ソフトが欠品なのは痛いね。

同じようなCP/M エミュレータ基板でサザンパシフィック版は64180搭載だった。
といってもメモリ拡張されていたわけじゃなかったけど。あの種、一時期流行ったね。

112 ：ナイコンさん：2021/03/30(火) 22:56:00.01 .net

>>77
ボクちゃんはZ80A世代しか知らないんだろうけど
8080や無印のZ80は2MHz動作だったんだぜ…

Z80Aの比較対象が碌に無かったから、Z80Aの割にはたいして速くないなーとは思っても
当初はまあこんなもんかー程度にしか思わなかった

S100バス機のZ80A搭載機やZ80カードとか既に存在はしたが結構いいお値段だったし
バス速度は言うまでもないしな…

113 ：ナイコンさん：2021/03/30(火) 23:20:58.95 .net

PC8001無印を、遅いとか思ったことないと、Z80Aの割にはたいして速くないとでは
全然違いませんか、おじーちゃん。

114 ：ナイコンさん：2021/03/30(火) 23:33:45.89 .net

動作クロックの割に遅いと感じたのは、むしろMSXかな?

115 ：ナイコンさん：2021/03/30(火) 23:34:03.84 .net

ベンチマークとして
画面スクロールの速さを比較するのが
分かりやすかった
そのやり方だとPCとMZは有利だった

116 ：ナイコンさん：2021/03/31(水) 00:02:44.49 .net

スクロールなんて2画面あるなしで8801不利すぎや

117 ：ナイコンさん：2021/03/31(水) 03:10:42.46 .net

IntelまたはAMDのマルチコアで動くZ80エミュある？

118 ：ナイコンさん：2021/03/31(水) 03:20:22.40 .net

マルチコアの要件は何のため？

119 ：ナイコンさん：2021/03/31(水) 06:17:19.78 .net

ふつうシングルだから

120 ：ナイコンさん：2021/03/31(水) 06:52:31.55 .net

たいていのエミュレータはマルチコアでも動くだろ
有効に活用してるかどうかは知らんけど

121 ：ナイコンさん：2021/03/31(水) 06:57:03.47 .net

あははははw

122 ：ナイコンさん：2021/03/31(水) 09:01:11.28 .net

そもそもZ80のエミュレーションなんて今のCPUなら片手間で十分だろ

123 ：ナイコンさん：2021/03/31(水) 11:23:41.58 .net

　すぐに目に留まるというか，驚愕するのは，i9-11900K（1：1＆ABT）の
恐るべき消費電力の高さだろう。実ゲーム実行中で見ると，Borderlands 3
実行時に247Wという驚愕の最大電力を記録している。ゲーム，非ゲームを
通して最も高かったのは，PCMark 10実行時に記録した329Wで，
CPU単体としては記録的な最大消費電力と言える。
　
https://www.4gamer.net/games/492/G049235/20210330031/
https://www.4gamer.net/games/492/G049235/20210330031/TN/046.png

124 ：ナイコンさん：2021/03/31(水) 11:54:24.33 .net

デスクトップはまだ14nmなんだろ
どうかしてるよまったく…

125 ：ナイコンさん：2021/03/31(水) 15:47:04.85 .net

マルチCPUのZ80システムをエミュレートしたいのとは違うのね

126 ：ナイコンさん：2021/03/31(水) 18:20:01.24 .net

>>122
20年ぐらい前でもZ80CPUのエミュレートだけならシングルコアで十分で、ちから余りまくりだったしなあ
68000のエミュレートですら十分だったような。

127 ：ナイコンさん：2021/03/31(水) 20:39:53.54 .net

英国で1988年ごろ売られていたAtariSTやAmigaでは
CP/Mのエミュレータがオマケで添付されていた。彼国の
小中学生向きで普及していたSinclair zx spectrum がZ80機で
無改造でCP/M走らせられたとかが影響していたらしい。

128 ：ナイコンさん：2021/03/31(水) 21:31:12.18 .net

同期コストの高さを知らない奴はすぐマルチコア対応しろというから困る。
たいていは遅くしかならん。必要なら自分でコード書けよと。

129 ：ナイコンさん：2021/04/01(木) 05:41:45.34 .net

>>123
消えろ、糞荒らし野郎

130 ：ナイコンさん：2021/04/01(木) 06:39:40.20 .net

今だとZ80のエミュでFUZIXというLinuxもどきのOSが使えるね
Z80以外にも6502や6809、68000、ARMにも移植されてるみたい
セルフコンパイルはできないみたいだけど、クロスコンパイルで自作プログラムも作れる
Z80の場合、CコンパイラはSDCCを使う

131 ：ナイコンさん：2021/04/01(木) 07:26:20.30 .net

Z80のエミュ位なら心得あれば自作でもいける
裏命令まで実装するとなると知識が必要だけど

132 ：ナイコンさん：2021/04/01(木) 21:35:30.40 .net

アセンブラかデフォのこのスレで何がマルチコア対応ガーだよ。
ム板のマルチスレッドスレにでも池、初心者。

133 ：ナイコンさん：2021/04/02(金) 03:27:49.82 .net

>>111
あったあった6418０ボード。
その後ドフでNTT AngelNet端末買ったら中にこのMPU入ってた。

134 ：ナイコンさん：2021/04/02(金) 03:37:30.69 .net

>>114-116
微妙にオフトピ(80186)だけどHP200LXって電卓PCが体感遅かったな。
比較対象が中古の98（8086　8MHz）だったからこの差も仕方ないが

135 ：ナイコンさん：2021/04/03(土) 13:00:24.12 .net

>>130
エミュレータじゃなくて実機なら面白そうなんだけどな。
東芝84C015（Z80ファミリでコテコテに固めたSoCのご先祖みたいなやつ）で動くならちょっと欲しいかも。

136 ：ナイコンさん：2021/04/03(土) 13:35:44.36 .net

uzixなら実機のMSXで動くよ。スロットをMMUとして使うけど。

137 ：ナイコンさん：2021/04/10(土) 02:54:17.66 .net

MSXか・・・今から入手ってのも何だなぁ。ビデオ入力付きモニタもないし(´・ω・｀)

138 ：ナイコンさん：2021/04/10(土) 04:32:32.89 .net

親の持ってるテレビという受信機に映るよ

139 ：ナイコンさん：2021/04/10(土) 10:02:08.95 .net

コンポジットのアップスキャンコンバータあるよ

140 ：ナイコンさん：2021/04/10(土) 17:33:56.13 .net

1chipならVGAに表示可能

141 ：ナイコンさん：2021/04/10(土) 21:23:05.78 .net

いまどきの4k有機TVでもアナログビデオ入力端子ってあるでしょ。
俺のregza にはあるよ。msxに繋げたことはないけど。

142 ：ナイコンさん：2021/04/10(土) 23:02:14.69 .net

モニタとテレビの区別もつかないレグザ持ちw

143 ：ナイコンさん：2021/04/10(土) 23:29:53.34 .net

>>142
まあ言うても
MSX自身が主にTVに繋ぐものだったし、
モニタにビデオ端子が無いならビデオ端子があるTVをモニタとして使えば良い
と言うだけの話だろう。
頭硬いぞ

144 ：ナイコンさん：2021/04/13(火) 12:06:20.60 .net

そもそもビデオ入力付きモニタとかNECのPC-TVシリーズしか知らん。

145 ：ナイコンさん：2021/04/13(火) 15:29:37.95 .net

X68000の純正モニタもビデオ入力ついてたよ

まあ、テレビチューナーもついてたけど

146 ：ナイコンさん：2021/04/13(火) 17:09:41.38 .net

話巻き戻してｽﾏﾝが、スレタイに8086があるので普通にMINIX1.0使えたからなぁ、ってのも。
実物を動かしたことないが。

147 ：ナイコンさん：2021/04/13(火) 18:39:45.25 .net

>>143
そう言うことは>>137に言ってくれよ

148 ：ナイコンさん：2021/04/13(火) 21:28:03.67 .net

>>145
類似品といえば寺モニタとかね。液晶モニターのマルチメディア対応製品では
sharpにBU-M15X1という製品がまれにオクで見かける。1024*768の15インチXGA。
コンポジットとVGA15ピン。アナログ地上波チューナー内蔵。赤白ファミコンみたいな
RFオンリーな機器持ちには便利。Atari800みたいな米国仕様のRFオンリー機はわからんけど

149 ：ナイコンさん：2021/04/13(火) 23:48:38.44 .net

>>147
143がケチ付けたことへの返信だから間違ってない

150 ：ナイコンさん：2021/04/14(水) 02:05:59.16 .net

テラモニタ持ってる。たぶん最後の人である。

151 ：ナイコンさん：2021/04/14(水) 06:51:24.68 .net

>>149
>>143がケチを付けたのが間違ってないことはよくわかった
難癖レベルの頓珍漢だけどw

152 ：ナイコンさん：2021/04/14(水) 16:21:07.36 .net

MSXはテレビ前提の低解像度だったのが日本語扱う上で致命的だったな。

153 ：ナイコンさん：2021/04/14(水) 19:50:04.97 .net

ふんわりしてジャギー見えなくて滑らかな日本語

154 ：ナイコンさん：2021/04/14(水) 23:17:00.61 .net

昔のソフトはブラウン管のボケとか、NTSCをデコードするときの偽色を利用してたな

155 ：ナイコンさん：2021/04/15(木) 18:44:31.48 .net

実際そんなソフト見たことないや

156 ：ナイコンさん：2021/04/15(木) 20:03:30.91 .net

>>155
Apple ][ でそのテクが使われてたのは何かで見た記憶がある
WikipediaによるとPC-6001のポートピア連続殺人事件で使われてたらしい
後継機種のPC-6000mk IIではRGBディスプレイで色がくっきり出るようになったから滲みを利用してたゲームが白黒になってしまい色が出ないって言う問い合わせが来たらしいw
https://ja.m.wikipedia.org/wiki/PC-6000%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA

157 ：ナイコンさん：2021/04/27(火) 19:26:41.23 .net

スレチだが8085ののった基板を職場で見かけた。もう使ってないようだが。

8085だとNEC TK-85かCASIO FP-200くらいしか思いつかないが、
パソコン(個人向けコンピュータ)以外では使いであったんだな。

158 ：ナイコンさん：2021/04/27(火) 20:01:10.33 .net

PC-8201が8085(のCMOS版の80c85)だね
最近だと火星探査機マーズ・パスファインダーとか

159 ：ナイコンさん：2021/04/27(火) 20:32:58.00 .net

>>157
セラミックパッケージのヤツか宇宙で大活躍

160 ：ナイコンさん：2021/04/28(水) 08:00:01.92 .net

>>157
パソコンはZ80に席巻されちゃったからあまり見かけないけど小規模組込用ではそこそこ使われてたよ

161 ：ナイコンさん：2021/04/28(水) 18:14:44.58 .net

アドレスバスとデータバスがマルチプレクスされていたね

162 ：ナイコンさん：2021/04/28(水) 19:03:09.54 .net

火星に行ったのって80C85…だよねたぶん

163 ：ナイコンさん：2021/04/28(水) 19:58:25.52 .net

だね、Sojourner Rover に搭載されてた

164 ：ナイコンさん：2021/04/28(水) 21:30:04.52 .net

PC-8201・・・そうだ忘れてた、それもあった。NECの赤くてカッコいい奴ｗ

FP-200（たしか沖の3MHz品）も省電力を強いられる乾電池駆動だし、
8085はZ-80よりcmos CPUの流通が早かったんだっけ？

165 ：ナイコンさん：2021/04/29(木) 05:39:07.03 .net

組込用に利用されてて組込だと省電力の要望も多いから早くからC-MOS版が開発されてたらしい

166 ：ナイコンさん：2021/04/30(金) 14:59:41.65 .net

>>161
8255とタイマーとRAMが融合した8155をつなげる時にピン数が節約できてとても便利

167 ：ナイコンさん：2021/04/30(金) 18:11:16.58 .net

8085にはHLレジスタの右シフトなんて隠し命令があったんだな
16bit乗算が370クロックくらいでできるから6809と互角じゃねぇか

168 ：ナイコンさん：2021/05/01(土) 03:58:17.63 .net

2MHzの370クロック
うっとりするほど遅い

169 ：ナイコンさん：2021/05/01(土) 07:39:37.76 .net

6809は8bit x 8bit ⇒ 16bit を11クロックで行けるからどう見ても16bit x 16bitに370クロックもかからんと思う
なにをもって互角って言ってるんだろ

170 ：ナイコンさん：2021/05/01(土) 08:15:09.39 .net

6809の8bit乗算はデータのロードと結果の積算も含めると30クロック程度かかるから
16bit乗算は120クロック以上かかるんだよ
固定小数点のシフト操作もさらに大きい負担になる
FM-7のサブCPU 相手なら勝てる

171 ：ナイコンさん：2021/05/01(土) 10:33:40.98 .net

>>170
> 16bit乗算は120クロック以上かかるんだよ
だから何？
120以上は370も同等だってか？w

172 ：ナイコンさん：2021/05/01(土) 11:14:44.63 .net

大昔のCPU（MPU）で乗算の性能を争っても虚しいだけ。
大昔のCPU（MPU）を今でも利用するには、どうしたら良いか。
尚、＜捨てる＞と言う回答は板的にも断固として認めない。

173 ：ナイコンさん：2021/05/01(土) 11:44:59.20 .net

>>168
2MHzは8080だろ、8085は、もう少し高クロックじゃ?

174 ：ナイコンさん：2021/05/01(土) 12:53:19.72 .net

>>168
8085は3MHzと5MHzだから5MHzだったら同等でしょ
8085は8080からのソフト資産が多かったから使いやすかった

175 ：ナイコンさん：2021/05/01(土) 13:08:26.00 .net

>>172
虚しいと言い切ってしまうとスレの意義がなくならないか？
乗算は性能を比較するうえで格好の材料なんだし

176 ：ナイコンさん：2021/05/01(土) 17:19:34.21 .net

虚しいかどうかは人によるだろうけど8085と6809の乗算性能が互角とか言うのはどうかと思う

177 ：ナイコンさん：2021/05/01(土) 21:22:31.26 .net

Z80はどれぐらいだろ

16ビットのシフト命令がないから遅いかなあ

178 ：ナイコンさん：2021/05/01(土) 21:59:15.82 .net

速度比較だと世代的には、
8085(3MHz)=Z80(4MHz)=6809(1MHz)
8085(5MHz)=Z80(6MHz)=6809(2MHz)
なのかな？

179 ：ナイコンさん：2021/05/01(土) 22:06:45.12 .net

8085なんて当時聞いたこともなかったわ。

180 ：ナイコンさん：2021/05/02(日) 00:40:08.74 .net

>>179
あなたの言う当時とはいつの事かわからないが
NECならTK-85があったし組み込み用にかなり使われていた

181 ：ナイコンさん：2021/05/02(日) 01:12:24.14 .net

RAMの使用料が少なくてすむ組み込みにはチップ数を減らせる8085は圧倒的に有利だったらしいね
多くのRAMを使いたいパソコン系統でだと、DRAM接続のしやすいZ80が8080やら8085より圧倒的に有利だったから、用途別で住み分けてたんだろ

182 ：ナイコンさん：2021/05/02(日) 02:54:44.91 .net

高校の教科書にはZ80全命令と8085全命令が書かれてたからそれなりに有名な石だと思ってた。

183 ：ナイコンさん：2021/05/02(日) 06:21:22.71 .net

PC板なのに組込連呼されても困りますよ、おじーちゃん。

184 ：ナイコンさん：2021/05/02(日) 06:29:43.17 .net

TK-85は組み込み基板ではなくって、普通のマイコンなのでこの板の範疇だね

185 ：ナイコンさん：2021/05/02(日) 06:37:31.36 .net

TK-85なんてPC雑誌で見たことないわ。

186 ：ナイコンさん：2021/05/02(日) 06:58:23.13 .net

TK-85は1980年発売でPC8001の後か。PCブームの私とは世代が5年ぐらいズレてますな。
パソコンをマイコンと呼ぶおじーちゃんがいるけど、やっぱりマイコンとパソコンには明確な壁がありますな。

187 ：ナイコンさん：2021/05/02(日) 09:31:34.44 .net

ROM-BASIC載せなかったシャープ系のじーちゃんがずっとマイコンって言ってるかんじ
MZのMはマイコンの略だから？

188 ：ナイコンさん：2021/05/02(日) 09:35:04.55 .net

パソコンの黎明期にはマイコンと呼称されていたこともあるし
1980年と言えば41年前なので、当時の5年の違いをこと更強調し
明確な違いあると主張しても第三者には説得力がゼロでズレてるなと。

189 ：ナイコンさん：2021/05/02(日) 09:44:20.71 .net

当時、5年違ったらもう話が通じませんよ。
X1が5年でX68000になるのですから。テープ時代からの人とFDD時代からの人ですよ？

190 ：ナイコンさん：2021/05/02(日) 09:59:23.21 .net

これはPCに見えますか？　一般人の感覚はこんなものですよ。

見えない
Apple I
TK-85

見える
Apple II
PC8001

191 ：ナイコンさん：2021/05/02(日) 10:01:41.19 .net

>>189
5年違ったら当時は話が通じないと言う趣旨は理解するけど、それから30年以上経った今でも
理解できないと言うのは寛容力も勉強量も小さ過ぎ。この間、パソコンのメモリは
1000 × 1000 になったと言うのに相変わらず脳のキャパは 64KB のままか。

「マイコン」と呼ばれるものは4種類あります。
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14132060584
当時主流のコンピュータであるメインフレームやミニコンピュータといった、
建物1つや部屋1つくらいの大きさのものより小さいという意味で、現在のパソコンと同じような位置づけです。

マイコンという呼び方は1970年代から1980年代にかけて一般的であったが、同様な製品を現在はパソコンと呼ぶ。
ttps://ja.wikipedia.org/wiki/マイクロコンピュータ

192 ：ナイコンさん：2021/05/02(日) 10:08:53.90 .net

というかNECもAppleも自分で呼び方変えてるし。
メーカーが自社製品をそう呼んでるのだからそうでしょうということ。

193 ：ナイコンさん：2021/05/02(日) 10:19:08.84 .net

>>190
そもそも、この板に常駐する人の意識は一般人の感覚と違うことを理解しような。

尚、君の趣旨を全面的には否定はしない。
流石に、「4ビットマイコンの基板（画像）」がリンクされて「何、それ？」と尋ねた際に
「有名なマイコン基板だ、知らないとはモグリ」のレスには「はぁ？」とは思ったことはあるから。

194 ：ナイコンさん：2021/05/02(日) 10:27:00.96 .net

>>187
＞MZのMはマイコンの略だから？
それ、新説、珍説でないのか？ 下のように説明されてる。
MZ（-40K）の名前の由来は風呂ブザー用に用意してあった登録コードを流用したものであった
https://ja.wikipedia.org/wiki/MZ_(コンピュータ)

それはそうと、カセットテープ前提の「クリーン設計」ほど「クソ設計」はないなと自分の感想。

195 ：ナイコンさん：2021/05/02(日) 10:30:48.27 .net

TK-80はそれしか無かったら売れたけど既にPC-8001があるのにTK-85買う奴なんてそんなにいなかったし>>185の言うように雑誌で広告を見た記憶がない
組込みに使われてたのは事実だけどその手の企業に居るとかでないと8085なんて知らなくて当然だと思うぞ

196 ：ナイコンさん：2021/05/02(日) 10:38:20.34 .net

だから、一般の感覚というよりメーカー(NECもAppleも)が言い方をはっきり変えてますな。
なのでメーカーと一般人は同じであなたたちがおかしいのです。
おそらく電磁波のせいでしょう。マイコン時代は基盤むき出しでEMC対策は皆無でしたからな。

197 ：ナイコンさん：2021/05/02(日) 10:51:44.70 .net

88もFDD装備でもROM-BASICから立ち上がるとFDに保存できないんだから十分クソ設計です。

198 ：ナイコンさん：2021/05/02(日) 13:55:35.90 .net

マイコンって1977年ごろ電気大学の安田寿明センセの大ベストセラー
講談社新書ブルーバックスのマイクロコンピュータ本で初登場な造語でしょ。
あのシリーズ三部作の2冊目だったかに8085が近々発売されるという記述があって
当時のインテルジャパンにそれ何時よ？って電話かけたことあるよ。
インテル謹製の評価トレーニングKITのSDK-85を自腹で買って手半田したな。
NECのTK-85は完成品。76年にTK-80をKITで売ったら爆発的に売れて未完成修理品の
尻拭いサポートという地雷が大爆発。エンジニア総出で日曜休日返上のビットイン徹夜
大作戦敢行で疲れ果ててねの完成品。と当時の中の人のボヤキ話を聞かされたことがある。

安田寿明 (1977年3月). マイ・コンピュータ入門―コンピュータはあなたにもつくれる. 講談社. ISBN 9784061179134
安田寿明 (1977年9月). マイ・コンピュータをつくる―組み立てのテクニック. 講談社. ISBN 9784061179288
安田寿明 (1978年4月). マイコンピュータをつかう―周辺機器と活用の実際. 講談社. ISBN 9784061179479

https://ja.wikipedia.org/wiki/安田寿明

199 ：ナイコンさん：2021/05/02(日) 14:35:25.07 .net

TK-85って現物も写真とかも見たことないんだけど、キー入力や表示ってやっぱり8279が受け持ってたのかな

200 ：ナイコンさん：2021/05/02(日) 14:41:52.44 .net

>>199
8255だよ
キースキャンはCPUがポーリングして7セグはDMAだった

201 ：ナイコンさん：2021/05/02(日) 14:54:33.18 .net

>>197
シャープユーザーなのかな？ DISK-BASICで立ち上げれば良いのではと？
FMユーザーなので88は知らないけど。せめて「QD」がないと「クリーン設計」は（略

202 ：ナイコンさん：2021/05/02(日) 18:46:42.33 .net

BASIC ROMが完成しなかったからRAMにして
クリーンコンピュータということにした

203 ：ナイコンさん：2021/05/02(日) 19:59:47.65 .net

>>198
神田の古書店で買ったよそれ。
巻が進むにつれて実用的な話になったけど、なぜかわくわく感が減っていった。

204 ：ナイコンさん：2021/05/02(日) 20:03:11.09 .net

>>199 >>200
8279の実機見た記憶がない。採用機あったん？

205 ：ナイコンさん：2021/05/02(日) 20:54:46.84 .net

ぐぐると開発キットで採用例あるね
http://www.st.rim.or.jp/~nkomatsu/evakit/SDK85.html
これとか見ると小ロットな組込み機器向けみたい
http://www.st.rim.or.jp/~nkomatsu/intel80peripheral/i8279.html

206 ：ナイコンさん：2021/05/02(日) 23:34:37.96 .net

え？　マイコンってmy computerの略で使ってたの?

207 ：ナイコンさん：2021/05/02(日) 23:54:36.70 .net

だとしたらパソコンをマイコンと呼ぶのも勝手だなw

208 ：ナイコンさん：2021/05/03(月) 00:04:50.24 .net

月刊マイコンが終盤にMy Computer Magazineって書いてたのに

209 ：ナイコンさん：2021/05/03(月) 00:10:03.09 .net

仕事のはオフコンで問題ないけど、
友達の家に遊びに行ったときはユアコンとか言ってたんか？

210 ：ナイコンさん：2021/05/03(月) 00:15:34.98 .net

ググったらNECはTK-85をマイクロコンピュータって呼んでて安心した。

211 ：ナイコンさん：2021/05/03(月) 00:24:43.83 .net

>>209
おまコン
とかじゃないか

212 ：ナイコンさん：2021/05/03(月) 03:22:52.48 .net

81年頃の所期のパソコンとかだと、四十年もの、不惑の歳だから、フワコン?

213 ：ナイコンさん：2021/05/03(月) 05:16:46.92 .net

当時ナイコンでした

214 ：ナイコンさん：2021/05/03(月) 10:46:58.49 .net

ミニコンに対してのマイクロコンピュータなのか
マイクロプロセッサを使ったコンピュータだからマイクロコンピュータなのか
どうなの？
1970年代のミニコンはPDP-8が12bit、PDP-11が16bit、PDP-10が36bitとかの時代みたい
PDP-11はUNIXがまだVersion 6とかVersion 7の頃のターゲットマシンとして有名
PDP-10はLISPを使うために設計されたミニコンだったみたい
プログラミング開発環境としても洗練されてていろんな言語が使えたみたい
ビルゲイツが大学にあったPDP-10上でBASICを開発した話は有名

>>212
1981年に当時16歳くらいだとして、ユーザは現在56歳くらいかな？
当時、25歳くらいなら現在65歳くらいか

215 ：ナイコンさん：2021/05/03(月) 11:24:35.22 .net

>>212
言い足りなかったかも?

ユーザーじゃなくてコンピュータ自体の年齢（開発とか製造とかからの時間）が「不惑」ぐらいに達してるということで

ユーザーが不惑だと、古く見てもWin98かXPあたりかなあ

216 ：ナイコンさん：2021/05/03(月) 11:35:23.25 .net

>>214
マイクロコンピュータの呼称の由来は色々考えられる、当時でも定説はなかった記憶。
1）大型やミニコンと比較して
2）マイクロプロセッサを使ったから

マイクロプロセッサを使えばコンピュータを小型化できるだろし。

それよりは、スレタイにあるMPU（CPU）を使って現在、何をしてるかに興味津々。
因みに自分もコードは書いてるけど、「twitter」にはポケコンで驚異的な人が出現してる。

217 ：ナイコンさん：2021/05/03(月) 13:01:51.98 .net

8085に追加した新命令が封印された理由って何なんだろ
乗除算や高級言語の高速化に効果のある切望されいる命令のはずなのに
63C09のネィティブモード程じゃないが惜しい

218 ：ナイコンさん：2021/05/03(月) 13:39:45.26 .net

予期した通りの性能がでなかったとか何らかの誤動作が発覚したとか動きが微妙に予想外だったとか色々あるんでね

後に公開する予定の隠し機能だったが公開する機会なく終わったとかさ

噂によればペン４にも謎の隠し機能があった（マイクロコード入れ換えてｲﾀﾆｳﾑ命令を実行できる動作モードを搭載する予定だとか?）と伝え聞くが、肝心の板が終わってたので公開する意味がなくなって封印だとか?

219 ：ナイコンさん：2021/05/03(月) 14:49:02.80 .net

しったかなのかホラ吹きなのか
Itanium(アイテニアム)を板と略すのも初めて聞いた

220 ：ナイコンさん：2021/05/03(月) 15:37:47.82 .net

>>217
違法コンパチ品がリバースエンジニアリング解析でパクられて
デッドコピーされたものかどうかを簡単に見出すためのトラッピングとか？
明示バグを混入させたインタプリタとか。誤植混ぜ込んだ辞書データとか。
コピー品識別のための証拠として「混ぜ混ぜ」入れ込む例は結構あるみたいね

Hidden Instructions for the 8085
https://www.ee.iitb.ac.in/~sumantra/courses/up/undoc_8085.pdf

221 ：ナイコンさん：2021/05/03(月) 16:04:24.98 .net

>>220
そういう目的ならわざわざ有用な命令を仕込む必要はないだろ

222 ：ナイコンさん：2021/05/03(月) 16:21:51.46 .net

CP/Mの存在を考えると組み込み系命令以外は邪魔ってことになるのかな

223 ：ナイコンさん：2021/05/03(月) 16:25:40.31 .net

上がIT音痴ジョブスのような思いつき行動タイプだと
トンデモな仕様変更なんて日常茶飯事で開発現場も混乱してドキュメントに書き忘れたのさ。
仕様書と実装が全然違う糞プロジェクトは何度も見てきた。

224 ：ナイコンさん：2021/05/03(月) 17:17:49.81 .net

こんなこともあろうかとEM64T入れてあった
AMD64の丸パクリ

225 ：ナイコンさん：2021/05/03(月) 17:20:11.72 .net

HT ハイパースレッディングも
イネーブルすると論理CPU数が倍になるやつ

226 ：ナイコンさん：2021/05/03(月) 20:00:47.06 .net

私の持ってる6309と8052BASIC大丈夫だろうか・・・・・
違法コンパチ品だったら嫌だな。まだ組んでないし不安

227 ：ナイコンさん：2021/05/03(月) 20:12:45.26 .net

>>224
元々入れてあったのを有効にしたんじゃなくて、MSの要求で元のヤツ（有効にする前の隠し機能、まだ使用不能だった）と入れ換えで実装したんだろ

当初予定の64ビット拡張をホントに積んで出荷されたチップが実在するかどうかは知らんけどさ

228 ：ナイコンさん：2021/05/03(月) 20:38:38.14 .net

>>224
AMDと違うもの作っても使ってやらんとMSに言われたら嫌がらせ目的の新機能は載せられん
せこい機能をﾁﾋﾞﾁﾋﾞと増設するうんこ野郎ざまぁ、と思ったが体質は今も変わらん

229 ：ナイコンさん：2021/05/03(月) 21:11:45.94 .net

そのMSの手拭きのせいで64bitWindowsの設計が酷いことに。

230 ：ナイコンさん：2021/05/03(月) 21:18:20.55 .net

元々のインテルプランだとアドレス64ビット拡張しただけで命令セットはほぼ変化なしだったはず

231 ：ナイコンさん：2021/05/03(月) 21:26:50.88 .net

PenProで物理アドレス拡張してるし、データバスも64bitに拡張されてた。

232 ：ナイコンさん：2021/05/03(月) 23:12:27.88 .net

脱線・発展は、この板の常として32bit拡張の64bitはAMDが先行した感はある。
先行したと言うよりAMDの資金力ではそれが精一杯的。対して資金力が豊富な
インテルは新機軸に挑戦したけどメモリでもやった失敗をまたやっちまった感。

>>231
＞PenProで物理アドレス拡張してるし、データバスも64bitに拡張されてた。
どのような経緯で判ったのかと。PenProの内部はリスク風32ビットの80960技術の転用と言われてるけど。

233 ：ナイコンさん：2021/05/04(火) 04:25:17.79 .net

NECみたいに半導体が作れなかったんでバグがあるとヤバイというので
クリーン設計に。

234 ：ナイコンさん：2021/05/04(火) 04:41:01.57 .net

ARMは64bit化でうまいことやったね
命令セットを一新して整理できたし、ARMの欠点だったものを捨てることができた
64bitで命令セットは一新したけど
実装的にはそれほど負担にならない程度の新命令セットだったしな

235 ：ナイコンさん：2021/05/04(火) 15:24:51.61 .net

長かったなようやく今頃になってのx86超えか

236 ：ナイコンさん：2021/05/04(火) 19:01:50.04 .net

ARM64はむしろRISC-Vの登場を読めなかったのでもはや没落が約束されている残念アーキテクチャ

x86-64はAMDが386命令にプリフィックスをつけるだけという糞設計して残した呪い
命令長が最大で11バイトだか13バイトにも及ぶとか、単一命令長縛りのRISC系なら白目剥いて卒倒するよね
それでもμopに砕いて実行して使い物にしていったintelが化け物だっただけ

237 ：ナイコンさん：2021/05/04(火) 19:57:42.85 .net

RISC-Vは将来が約束されてない妄想アーキテクチャ。

238 ：ナイコンさん：2021/05/04(火) 20:59:50.59 .net

>>236
11バイトとか13バイトとか、すごく長そうな感じするけど、RISCでよくある（かつて主流だった）32ビット固定長命令に比べたら、わずか3個分

ちょっとした処理でも複数命令に分ける必要が出ることの多いRISCと比べたら、実は大して長くない（むしろ同等）とさえ言える

239 ：ナイコンさん：2021/05/04(火) 21:20:25.16 .net

複雑なものを分解してシンプルに考える、処理する　→普通で当たり前。Intelは正しい。
複雑なものは面倒だからそんなものは捨ててシンプルなものにする
　→使い物にならないものが出来上がる。

最適化をコンパイラ開発者に丸投げするような無能者は実装も丸投げする。RISC-Vの誕生。

240 ：ナイコンさん：2021/05/04(火) 21:51:46.90 .net

順番、逆じゃね?

手作業最適化が廃れてコンパイラ任せにするのが増えたからRISCが有用と考えられるようになって普及したんじゃね

コンパイラによる最適化がかかりやすいRISCとかかりにくいCISCで性能差が出たからリスク有利となったんだと思うが

241 ：ナイコンさん：2021/05/04(火) 22:04:31.98 .net

毎回コンパイルし直せば良いってUNIXでの文化からRISCでソフトで最適化すれば良いになったんだろうが、
バイナリ互換が欲しいとなると、結局半導体プロセスで最適が移動しまくってしまうのが困る
互換性重視したらもうCISCで変換すりゃ良いよなになった

242 ：ナイコンさん：2021/05/04(火) 22:10:01.06 .net

普通の最適化なら、多少ならプロセッサ違っても困らない程度の微少な差しかでないだろうけど、遅延分岐みたいなのは互換性考えなかったら遅延スロット数がプロセッサによって違ってしまうはずなんだよなあ
結局は互換性維持に注力せざるを得なくなってしまったわけで。

243 ：ナイコンさん：2021/05/05(水) 00:11:26.14 .net

まるでx86がCISCの代表みたいな言い方だな
もっと複雑なCISCだったVAXや680x0は消えていった
x86なんてストリング命令除けば、
ロード命令と演算命令もしくはストア命令と演算命令が1命令になってるだけで全然複雑じゃない
アドレッシングモードだってVAXや680x0と比べればかなり単純

244 ：ナイコンさん：2021/05/05(水) 00:13:14.80 .net

もう、MIPSだってMIPS32R6、MIPS64R6からは遅延スロットはなくなった
いつまでも古いRISCの揚げ足取りばかりしてても意味ないよ

245 ：ナイコンさん：2021/05/05(水) 00:20:31.52 .net

http://www.st.rim.or.jp/~nkomatsu/intel8bit/i8085.html
に記載されている8085の未定義命令だけどMAMEやTakeda氏のソースを見ると
RDEL 18 10 DE <- DE*2, E0 <- CY, CY <- D7
はDEの最上位ビットが最下位ビットにコピーされるローテート動作になっているので
CYを取り込むことはできないらしい
バグって非公開になったというのが真相かも

246 ：ナイコンさん：2021/05/05(水) 00:25:08.30 .net

いや、RISC-Vは使い物にならないという結論のレスだったんだが

247 ：ナイコンさん：2021/05/05(水) 00:40:46.86 .net

シロート意見でｽﾏﾝが、VAXも680x0も生みの親に殺されたようなもんかと。
殺した側のDEC Alphaとモトローラ88000も短命に終わったが

248 ：ナイコンさん：2021/05/05(水) 00:57:31.25 .net

>>237
RISC-Vは中国が他国依存や制裁対策の為に自前CPUの土台にしようとしてないか？
これに成功すると、中国製品の形で世界に広がる可能性が。

249 ：ナイコンさん：2021/05/05(水) 02:05:06.81 .net

アップルがM1マック出した途端に、無茶苦茶なARM推しRISC-V叩きが急増したよね
わかりやすい

250 ：ナイコンさん：2021/05/05(水) 03:30:03.31 .net

>>243
セグメント回りは複雑だったろ

251 ：ナイコンさん：2021/05/05(水) 03:32:19.62 .net

>>248
MIPSも今では中国企業の傘下の会社がもってるぞ

252 ：ナイコンさん：2021/05/05(水) 03:37:00.92 .net

枯れてるというのはほんと重要だから、M1もRISC-Vも失敗に終わると思う。

253 ：ナイコンさん：2021/05/05(水) 08:05:21.94 .net

8080から連綿と続くx86アーキテクチャは互換性によって発展した！(キリッ)

254 ：ナイコンさん：2021/05/05(水) 08:29:28.94 .net

過去の事考えるとAppleの言ってる事が眉唾臭くてしょうがない

255 ：ナイコンさん：2021/05/05(水) 08:45:58.23 .net

一時CISCの将来は危ぶまれたが、コードに互換性を持たせ、内部のアーキテクチャは
RISCの思想を取り入れパイプライン、予測分岐等が有効に機能したので生き残ったと考えてる。

256 ：ナイコンさん：2021/05/05(水) 09:49:04.97 .net

さすがに31段パイプラインはやり過ぎというか逆効果
分岐予測の的中率にループ判定入れんなと

257 ：ナイコンさん：2021/05/05(水) 10:27:57.42 .net

M1の3GHzとi7の5GHzで勝った負けたしてるし魔改造RISCの本領発揮だな
x86みたいな小汚いプロセッサはさっさと滅んでいいのよ

258 ：ナイコンさん：2021/05/05(水) 12:48:17.69 .net

ほんとマカーとRISC信者いうのは市場で負け続けてるのにマウンティングしてくるな

259 ：ナイコンさん：2021/05/05(水) 13:04:26.78 .net

パイプラインはRISCの思想なのか？
フォードシステムとかただの分担作業、流れ作業のことだろ。
アマゾンの原住民でもやってるレベル。

260 ：ナイコンさん：2021/05/05(水) 13:22:47.60 .net

>>252
M1は大口の顧客が確定的に存在するから失敗はないだろ

261 ：ナイコンさん：2021/05/05(水) 13:46:44.44 .net

枯れたと言うほどでないが元々スマホで使われてた物の延長だから実績はそこそこ

262 ：ナイコンさん：2021/05/05(水) 13:47:20.01 .net

RISC-VはHDDのコントローラで採用例があったりするしワンボードの基板も出て来ているので市場は立ち上がっていくと思う
ARMはパソコンで使うとした場合リファレンスがないのが問題
Appleがオープンにするとは思えないし
PCの場合はAT互換から逸脱した後でPC98等のリファレンスがあったのは大きいと思う

263 ：ナイコンさん：2021/05/05(水) 14:18:53.23 .net

ハードとソフトは切り離せるものではない。
picがエラッタ修正しないのは、修正すると既存コードが動かなくなるから。
x86がバイナリ互換をずっと重視してきたのもソフト資産が大切だから。
ならハードを仮想化すればいいと始めたJavaも大失敗で、もはやx86Linux向けに開発したらそれ専用。
arm-android向けならそれ専用。Write once, debug anywhere.が既に常識。理想はとっくに捨てている。

だからRISC-Vが単発でいくら利用されようが発展しようがない。
ハード実装企業が変わればコードの再利用は不可能。RISC-Vの失敗は目に見えている。
RISC-Vチップの開発を一企業が独占しないかぎりね。

264 ：ナイコンさん：2021/05/05(水) 15:05:46.24 .net

独占は成功の必要素ではない
RISCVを企業が独占したら更に早く捨てられる
ARMは公平で独占してないから伸びた
だからnVidiaが買収した時公平性に問題有りでもめてる
x86は独占しててもPC用に他に選択肢がない売れてる

265 ：ナイコンさん：2021/05/05(水) 15:08:39.65 .net

RISC-V連呼しだしてもう10年経ってるが既に失敗したと言えるのはではないか。

266 ：ナイコンさん：2021/05/05(水) 15:14:55.69 .net

>>262
WindowsRとかChromebookとかPCにもARMのヤツあるじゃん
マックとの互換性はないけども

267 ：ナイコンさん：2021/05/05(水) 15:23:11.83 .net

>>252
M1系(M2も？)はとりあえずMacとか市場付きなのでそれなりに残るだろう。
古参ではMIPSが一番微妙な立場なんじゃね？

>>263
Javaの未来が萎んだのはOracleが牛耳って有償化した事が大きい
代わりに.Net系がその地位を奪いつつあるのはJavaに対する皮肉。

268 ：ナイコンさん：2021/05/05(水) 15:33:25.73 .net

富岳がSPARC系を素てARM命令セット採用したように互換性もある程度は大事

シリコンの微細化と高クロック化はそろそろ限界に達してきているので
次世代半導体で一旦微細化が戻る方向で開発は無いのだろうか？
次世代半導体での試験作成で高クロックZ80とか6502とか出来ないだろうか？
ガラス基板上のZ80みたいに・・・。この技術は花開かなかったのか。

269 ：ナイコンさん：2021/05/05(水) 15:44:48.21 .net

SPARC系は高クロック化しにくかったから衰退したんだろ

SPARCやめてARMに切り替えたことで性能を伸ばせたんじゃないの

270 ：ナイコンさん：2021/05/05(水) 18:47:48.41 .net

科学の足を引っ張る競争入札に強いだけの迷惑企業と感じる

271 ：ナイコンさん：2021/05/05(水) 18:57:48.32 .net

よそで命令セットだけARMでCPUの基本設計は富士通SPARCの奴と共通と言ってるやしいたけど
そうなると高クロックも少電力性能も説明つかないよな

272 ：ナイコンさん：2021/05/05(水) 19:01:36.36 .net

ARMコアはARM一社で開発しないと互換性保証できないと思う。
仕様は決めて実装は各社勝手にやれって昔からの失敗パターン。

273 ：ナイコンさん：2021/05/05(水) 22:36:43.05 .net

>>269
＞SPARC系は高クロック化しにくかったから衰退

スカラ型スパコンCPUとしての一つの面ではその通りだと思う。

でも、京でSPARC系だから使いにくいとした反省で、使い易さの為にARM系命令セットになったはず。
https://pc.watch.impress.co.jp/docs/column/gyokai/1261786.html

＞ARMに切り替えたことで性能を伸ばせた

という訳でコチラは違うだろう。

>>271
https://news.mynavi.jp/article/20190702-852159/
＞具体的に命令を実行するマイクロアーキテクチャの多くは富士通が独自に開発してきたOut-of-Orderのプロセサコアを使っている。

こちらですかね。

高クロックも省電力もプロセスルールが京の45nm→7nmというのが大きいかと

274 ：ナイコンさん：2021/05/06(木) 11:25:51.17 .net

8080でも使える16bit×16bit乗算
40年前にこれがあれば、、、１.5ｆｐｓのフライトシミュレータが作れたかも
; DEHL <- DE * BC
　 LD A,D
　 LD HL,0
　 LD D,8
　 ADD A,A
loop1:
　 JP NC,skip1
　 ADD HL,BC
skip1:
　 ADD HL,HL
　 RLA
　 DEC D
　 JP NZ,loop1
　 LD D,A
　 LD A,E
　 LD E,8
　 ADD A,A
loop2:
　 JP NC,skip2
　 ADD HL,BC
skip2:
　 ADD HL,HL
　 RLA
　 DEC E
　 JP NZ,loop2
　 LD,E,A

275 ：ナイコンさん：2021/05/06(木) 14:31:30.29 .net

テキスト画面のフライトシミュレータ。つまり計器飛行シミュレータですね。

276 ：ナイコンさん：2021/05/06(木) 21:09:17.50 .net

月面着陸シミュレータ

277 ：ナイコンさん：2021/05/06(木) 21:20:45.91 .net

ルナーランダーね。ベクターグラフィクスの。
初出として見たのは1970年大阪万博IBM館。
米国館で月の石実物が展示されていた。マシンはsystem360。
複数端末接続で多人数が遊べた。メイン端末にはコンパニオンの
お姉様がガイド。見事着陸成功すると国旗掲揚画面で会場拍手

278 ：ナイコンさん：2021/05/06(木) 21:41:50.67 .net

日本で8080機ってあったの？

279 ：ナイコンさん：2021/05/06(木) 21:52:54.44 .net

パチモンCPUだがtk-80

280 ：ナイコンさん：2021/05/06(木) 21:59:44.92 .net

TK-80でフライトシミュレータするのか。
電卓内蔵のいろいろなゲームもあったから工夫次第では7セグで

281 ：ナイコンさん：2021/05/06(木) 22:04:29.57 .net

制限が多い環境で工夫して作るっていいよね

282 ：ナイコンさん：2021/05/06(木) 22:17:58.59 .net

>>278
タイトーのインベーダー

283 ：ナイコンさん：2021/05/06(木) 23:25:27.61 .net

>>274
なんかもう少しはなくなりそう(根拠なし)

284 ：ナイコンさん：2021/05/07(金) 11:32:09.92 .net

>>274
ちゃんと計算できてないな
やっぱり右シフト方しか16ビット加算で済ませることはできないようだ

285 ：ナイコンさん：2021/05/07(金) 16:48:29.78 .net

ぱっと見で
下24ビットからの繰り上がりがレジスタＤに反映されてないんじゃないかと思った

286 ：ナイコンさん：2021/05/07(金) 16:51:05.40 .net

未テストで納品すんなよ。

287 ：ナイコンさん：2021/05/07(金) 19:42:36.12 .net

ちゃんと計算できるだろ？

288 ：ナイコンさん：2021/05/08(土) 09:52:13.81 .net

お動いたじゃん！テスト終わった〜！

289 ：ナイコンさん：2021/05/08(土) 11:14:13.78 .net

１×１を計算させたら２になるし
テストしてないのは明らか

290 ：ナイコンさん：2021/05/08(土) 14:37:38.93 .net

>>274 こんな風にしてみてはどうか。下24からの繰り上がりも対応。
; DEHL := DE * BC ; min 445, max 723
　 LD HL,0 ;10
　 LD A,D ;4
　 ADD A,A ;4
　 JP NC,skp0 ;10
　 LD H,B ;4
　 LD L,C ;4
skp0:
repeat 7
　 ADD HL,HL ;11
　 ADC A,A ;4
　 JP NC,skp1 ;10
　 ADD HL,BC ;11
　 ADC A,0 ;7
skp1:
end repeat
　 LD D,A ;4
(続く)

291 ：ナイコンさん：2021/05/08(土) 14:38:12.57 .net

(290続き)
　 LD A,E ;4
　 LD E,H ;4
　 LD H,0 ;7
repeat 8
　 ADD HL,HL ;11
　 ADC A,A ;4
　 JP NC,skp2 ;10
　 ADD HL,BC ;11
　 ADC A,0 ;7
skp2:
end repeat
　 ADD A,E ;4
　 LD E,A ;4
　 LD A,0 ;7
　 ADC A,D ;4
　 LD D,A ;4

292 ：ナイコンさん：2021/05/08(土) 15:30:10.17 .net

>>290
修正ありがとうございます。8080もきっとやればできる子です
;HLDE <- DE*BC
　 LD HL,0
　 LD A,D
　 LD D,8
loop1: ADD HL,HL
　 RLA
　 JP NC,skip1
　 ADD HL,BC
　 ADC A,0
skip1: DEC D
　 JP NZ,loop1
　 LD D,A
　 LD A,E
　 LD E,H
　 LD H,0
　 PUSH DE
　 LD E,8
loop2: ADD HL,HL
　 RLA
　 JP NC,skip2
　 ADD HL,BC
　 ADC A,0
skip2: DEC E
　 JP NZ,loop2
　 LD E,A
　 LD D,0
　 EX DE,HL
　 POP BC
　 ADD HL,BC

293 ：ナイコンさん：2021/05/08(土) 17:04:27.36 .net

テストしないPGは使えない子、できない子です。

294 ：ナイコンさん：2021/05/08(土) 20:47:59.89 .net

>>292
ランダム値で100万回テスト合格。平均クロック数865

295 ：ナイコンさん：2021/05/08(土) 21:48:54.73 .net

当時、Z80か6809の8bitPCしか手に入らなかったのに

今年の「無駄な努力で賞」です。

296 ：ナイコンさん：2021/05/08(土) 23:04:42.54 .net

PC8201でフライトシミュレータをやりたいって変態がきっと何人かはいた

297 ：ナイコンさん：2021/05/08(土) 23:43:49.48 .net

Z80のフライトシミュレータは学祭で展示したことある
それなりに人気があった

298 ：ナイコンさん：2021/05/08(土) 23:48:08.31 .net

CP/Mのフライトシミュレータの動画がyoutubeにあるけど何してるかさっぱりわからない。
普通の人が着陸とか無理ゲー。まず滑走路に真っ直ぐ入れない。

299 ：ナイコンさん：2021/05/09(日) 00:01:24.00 .net

290-291もテスト通しました
100万回もやってませんけど、0000-FFFFHの全ての値が乗数と被乗数に最低１回は現れるようにしました。
無駄な努力賞ください笑
http://imepic.jp/20210508/860950

300 ：ナイコンさん：2021/05/09(日) 00:14:36.82 .net

フライトシミュレータ用途なら24ビットくらいあれば十分だし、画素数が少なければ16ビットでも行けるんじゃない？

8ビットPCって他に掛け算の用途ないの？

301 ：ナイコンさん：2021/05/09(日) 02:37:07.79 .net

よく昔話に出てくるPDPで遊ばれてたというスタートレックがむしろやってみたい。

302 ：ナイコンさん：2021/05/09(日) 03:32:08.05 .net

昔々、あるPDPに
スターとレックがおりました

303 ：ナイコンさん：2021/05/09(日) 04:56:07.94 .net

>>299
環境はND8080独立化ですか

304 ：ナイコンさん：2021/05/11(火) 06:41:05.99 .net

8080にこだわる割に、ザイログニーモニックなのはなぜ？
ザイログニーモニックの方が使いやすいけどね
日本語の書籍ではインテルニーモニックの本あまり見ないね
「Z80の使い方」という本もザイログニーモニックだし

305 ：ナイコンさん：2021/05/11(火) 08:20:39.54 .net

>>304
> 「Z80の使い方」という本もザイログニーモニックだし
いや、それは当たり前だろ…

306 ：ナイコンさん：2021/05/11(火) 08:47:07.88 .net

PC8801のモニタの逆アセンブラが何故かインテル式たったよね

307 ：ナイコンさん：2021/05/11(火) 10:04:14.91 .net

>>306
ザイログのセカンドソースではないパクリCPUだったからだな

308 ：ナイコンさん：2021/05/11(火) 10:16:37.19 .net

インテルニーモニックはアセンブラ、逆アセンブラがとっても作りやすい

309 ：ナイコンさん：2021/05/11(火) 10:41:43.69 .net

LDだけで操作の種類が決まらないなど、アセンブラはもう一段階場合わけが必要になり複雑になるが、逆アセンブラの複雑さはインテルでもザイログでもそうそう変わらない

310 ：ナイコンさん：2021/05/11(火) 12:38:33.76 .net

>>306
MSBASICがインテルコードだからな

311 ：ナイコンさん：2021/05/11(火) 14:37:15.27 .net

「Z80の使い方」って確か命令表に誤記あったよね。
大した誤りではなく読んでれば気づくようなことで、その後の版では直ってるのかもだけど。

312 ：ナイコンさん：2021/05/16(日) 20:56:46.13 .net

やべぇ>>290のコードがさっぱり分かんねえ。
歳食いたくないもんだなouz....

313 ：ナイコンさん：2021/05/16(日) 21:02:26.14 .net

初マシン語がカシオの8085機でさっぱり覚えられなかったが、次に使ったシャープのZ80機は楽に憶えられた。
8080の命令しか使わなくてもザイログ二モニックは便利だった。

ザイログ二モニックで有名な「ありそうで無い命令問題」はあまり苦にならなかった。

314 ：ナイコンさん：2021/05/16(日) 21:22:07.76 .net

条件ジャンプ命令はフラグ直書きのほうが普通に読みやすい。
短縮形のJxxのチップはどうも逆に直感的じゃないと思う。
チップごとに差があるし慣れるまでに時間がかかる。

315 ：ナイコンさん：2021/05/16(日) 23:50:11.82 .net

>>312
セミコロンから先はコメント
repeat 〜 end repeat はコード展開を繰り返すマクロ
それ以外でわからないとこある？

316 ：ナイコンさん：2021/05/17(月) 04:31:36.37 .net

頭の体操レベル

317 ：ナイコンさん：2021/05/17(月) 06:29:06.55 .net

ゲイリーキルドールもビルゲイツ(ポールアレンが8080エミュレータ作成)も8080用の開発には
ミニコン上で動く8080エミュレータを自作して開発してたんだな
アメリカでは大学や公共の機関がサービスしてた
時間貸しのコンピュータが使えたようだけど日本はどうだったの？
Apple II用のVisiCalcもMITの時間貸しコンピュータで開発されたとascii.jpの記事に書かれてるし

318 ：ナイコンさん：2021/05/17(月) 07:08:51.23 .net

>>317
公共は知らんけど大学は時間貸ししてたよ
学生が借りれたかはわからんけど教授なら借りれてたから教授に相談すればなんとかなったと思う

319 ：ナイコンさん：2021/05/17(月) 15:05:42.33 .net

無許可Z80で8080コードのBASICが動くダーティーコンピュータ！
こんなもんよく売ったよな
無知な時代で助かった

320 ：ナイコンさん：2021/05/17(月) 15:17:22.47 .net

何を言ってるのか分からない

321 ：ナイコンさん：2021/05/19(水) 02:01:55.74 .net

>>320
NECのZ80的な何かの事だろう。
PC8001等に入っているヤツ

322 ：ナイコンさん：2021/05/19(水) 04:34:08.14 .net

μPD780のことなら問題ない

323 ：ナイコンさん：2021/05/19(水) 07:43:51.57 .net

セカンドソースのことを無許可のパチもんと勘違いしてる人か
こりゃまた、えらく無知な人が来たな

324 ：ナイコンさん：2021/05/19(水) 11:09:22.31 .net

>>323
ザイログのZ80は
NECは無許可だろ
ライセンシーはシャープ

325 ：ナイコンさん：2021/05/19(水) 11:27:50.92 .net

>>324
8001をうりまくっていたころは。らしいね。
インテルと訴訟沙汰でスッタモンダした後年改悛して正規ライセンシー得たらしいが

326 ：ナイコンさん：2021/05/19(水) 12:37:04.16 .net

モトローラー「勝手な改造した日立を許さない！！」

327 ：ナイコンさん：2021/05/19(水) 14:57:33.08 .net

何を改変したんだっけ?

328 ：ナイコンさん：2021/05/19(水) 17:28:15.03 .net

NECはインテルチップのライセンス結んでたから自社チップを使ったPCを売るつもりだったが
性能でZ80に敵わなかったから、手が勝手に動いてリバースエンジニアリングしちゃったんだろ
だから周辺がインテルで固められてるんだな

329 ：ナイコンさん：2021/05/19(水) 18:36:44.28 .net

そもそもシャープはどういう経緯でセカンドソースのライセンスを得たのだろう
やっぱり電卓関係なのかな

330 ：ナイコンさん：2021/05/19(水) 21:09:03.18 .net

何もかもパクりあって発展してきたころがあるな。
その一番の恩恵はパクった企業ではなくユーザーだろう。

331 ：ナイコンさん：2021/05/19(水) 21:35:42.99 .net

8ビットの時代は、セカンドソース契約してる会社があるチップしか採用しないメーカーってのが少なくなかった
んだよな、たしか?

8ビットじゃないけど、IBMがPCに採用する際にインテルに複数のメーカー相手にセカンドソース契約するように要求したんだろ?

332 ：ナイコンさん：2021/05/19(水) 21:39:58.26 .net

DOS/Vや今のWindowsなんてIBM-PCのパクりじゃん

333 ：ナイコンさん：2021/05/19(水) 21:43:23.98 .net

>>327
6309のことなら
勝手にいろんな命令のクロック数を減らした
勝手に命令を増やした
勝手にレジスタを増やした
勝手に消費電力を減らした
勝手に最高クロックを上げた

334 ：ナイコンさん：2021/05/19(水) 21:55:27.90 .net

>>327
6809 ⇒ 6309 じゃね？
6801 ⇒ 6301 とかもあるみたいだけど

335 ：ナイコンさん：2021/05/19(水) 23:14:18.73 .net

究極の８ビット

336 ：ナイコンさん：2021/05/20(木) 00:54:04.42 .net

>>332
ソフトがハードの何をパクったんだろう。IBM PCのBIOSでもWindowsがパクったんだろうか。

337 ：ナイコンさん：2021/05/20(木) 01:25:55.69 .net

8bit時代後期には一番のボトルネックはCPUなのに
究極の8bit機を売り文句にされても困るよな。

338 ：ナイコンさん：2021/05/20(木) 05:21:35.29 .net

332が愚かな件について

339 ：ナイコンさん：2021/05/20(木) 05:22:32.81 .net

68000の高速版を出してもらって究極の16bit CPUを名乗ってほしかった
結局、68000は16MHz、20MHzの高クロック版が出ただけだったよね

340 ：ナイコンさん：2021/05/20(木) 07:17:46.30 .net

キャッシュ積んでないからCPUだけ高速化してもねぇ…

341 ：ナイコンさん：2021/05/20(木) 07:47:01.57 .net

>>332
DOS/VというOS自体はIBMが出したものなんだが、なんでパクリなんだろうな

342 ：ナイコンさん：2021/05/20(木) 08:42:43.66 .net

ibmのpc買いたい

343 ：ナイコンさん：2021/05/20(木) 08:45:55.06 .net

>>339
6809もだが、モトローラのMPUはクロックアップ耐性が無さ過ぎるから
Z-80のセラミックパッケージのなんか冷却すれば20MHzでも動いたとか
まあZ-80は外部バスが問題で高クロックでは正常動作しないから使えなかったが

344 ：ナイコンさん：2021/05/20(木) 10:51:39.24 .net

>>340
386あたりまでノーウェイトでメモリアクセスできてたのにキャッシュですか。

345 ：ナイコンさん：2021/05/20(木) 11:53:51.04 .net

>>344
386の頃まで68000を改善し続けろって？w

346 ：ナイコンさん：2021/05/20(木) 12:06:07.69 .net

>>344
68000って386よりもバスのタイミングがシビアでノーウエイト動作しにくかったじゃん
モトローラのマニュアルが、途中の版からいつのまにか、1ウエイト入れた動作タイミングに差し替えられてたぐらいに。

347 ：ナイコンさん：2021/05/20(木) 19:54:00.16 .net

ほとんどのDOS/V機や、今のWindows機の先祖の多くはIBM-PCのパクりじゃん
・・・ってことかと。

348 ：ナイコンさん：2021/05/20(木) 21:07:53.31 .net

至高はMac機だな

349 ：ナイコンさん：2021/05/20(木) 21:25:09.04 .net

>>345
どこの誰が68k機を究極の8bit機って呼んでたんだよw

350 ：ナイコンさん：2021/05/20(木) 21:34:19.93 .net

>>349
> どこの誰が68k機を究極の8bit機って呼んでたんだよw
そんなこと言ってるのはお前だけだろw

351 ：ナイコンさん：2021/05/20(木) 21:44:23.22 .net

>>350
流れ読まずにレスしてたのかよ。迷惑な奴だ。

352 ：ナイコンさん：2021/05/20(木) 22:28:36.16 .net

話の流れが読めてないお前が言うなよ…

353 ：ナイコンさん：2021/05/21(金) 01:13:06.23 .net

>>349
68000のデータバス8ビット化版である68008ならば、ひょっとしたら「究極の8ビットCPU」と呼ばれる資格を少しだけもってるかもしれない

354 ：ナイコンさん：2021/05/21(金) 02:56:29.73 .net

>>81
とすれば、8088搭載の初代IBM-PCは実は8bitパピコンだった。と言えちゃうのか胸熱だな

355 ：ナイコンさん：2021/05/21(金) 02:56:56.74 .net

安価ミスった

356 ：ナイコンさん：2021/05/21(金) 07:53:36.58 .net

>>353
それならダイナミックバスサイジングで8bit接続した68030だな

357 ：ナイコンさん：2021/05/21(金) 08:36:58.68 .net

68000は命令コードのデカさが致命傷

358 ：ナイコンさん：2021/05/21(金) 08:54:23.60 .net

命令長が大きいって点は、ARMのthumb命令とか含めた後発組RISCと大差がなく、出た当初みたいなメモリが少なかった時代に特有の欠点、今では欠点ではない。

むしろ、命令長が8ビット単位で可変なせいで複数命令の連続デコードが難しいせいでデコード回路が過度に巨大化してしまうあれの方が今ではコード体系の欠点が大きくなってる

359 ：ナイコンさん：2021/05/21(金) 09:16:32.23 .net

>>358
> むしろ、命令長が8ビット単位で可変
16bit単位だろ
レジスタ16本でアドレッシングモードがそこそこあるから命令長が長くなるのはしゃーない
複雑さから言ったらx86の足元にも及ばんし

360 ：ナイコンさん：2021/05/21(金) 09:34:21.77 .net

いやすまん

突然に名前も出さずにx86命令のことをいったから通じなかっただけ

8ビット単位じゃなく、68みたいに16ビット単位の可変長なら、少しはデコード回路の複雑さがましだっただろうなと、書きたかったんだ

361 ：ナイコンさん：2021/05/21(金) 09:37:56.09 .net

そんな差になるかなあ？
今なら長い固定長命令の短縮コード扱いで済むんじゃ？

362 ：ナイコンさん：2021/05/21(金) 09:52:53.15 .net

複数命令の同時デコードだぞ
現在注目中の命令はまだしも、次の命令がどこから始まるかを調べるのが負担
3命令4命令同時デコードしようとするんだから、次の命令がどこからどこまででその次がどこからどこまでで
という感じで複数の区切りを数クロックの時間内に確定させるんだぞ、それも命令実行前に。

363 ：ナイコンさん：2021/05/21(金) 10:12:27.56 .net

次の命令を一度に一つに絞ろうとするから大変になる
見なしで全部デコードしようとして、確定して行く順で無効化してって残ったのが次の命令で良い

364 ：ナイコンさん：2021/05/21(金) 10:16:13.01 .net

どうにかして5bitオフセットを１ワードの中に詰め込んで欲しい

365 ：ナイコンさん：2021/05/21(金) 12:05:06.26 .net

>>363
いちおう、近年のモデルではデコードでも投機的〜をやってるとは聞くよ
ただ、最短1バイトで長いのは20バイトごえのすさまじい可変長だからな
回路規模もパイプラインのステージ数も、相当な負担になってるらしいよ

366 ：ナイコンさん：2021/05/21(金) 13:29:39.45 .net

>>362
μOpに変換して並び替えまでやってる時代に命令の切れ目探すのが負担とか何寝ぼけたこと言ってるんだよw

367 ：ナイコンさん：2021/05/21(金) 15:15:37.92 .net

x86のデコーダ部分はかなり熱持つ

368 ：ナイコンさん：2021/05/21(金) 15:40:52.84 .net

x86にx64が追加されたときデコードのために消費電力増えたなんて聞いたことないな。

369 ：ナイコンさん：2021/05/21(金) 15:44:48.89 .net

>>362
何が問題なのかさっぱり分からん。
おまえが複雑だと考えるものはワイヤードロジック一発で決まるものばかりだぞ。

370 ：ナイコンさん：2021/05/21(金) 17:28:50.17 .net

>>366
そのμOPへの変換が、処理が重いんだよ
パイプラインの段数見てみ、デコード段がすごく深いだろ、しかも半分ぐらいは変換までで使いきってるだろ

371 ：ナイコンさん：2021/05/21(金) 17:34:41.27 .net

>>370
> そのμOPへの変換が、処理が重いんだよ
誰もそこが軽いなんて言ってないけどどうした？
まさかと思うけど命令の切れ目探すのとμOpへの変換が同じとか思ってないよね？w

372 ：ナイコンさん：2021/05/21(金) 18:10:18.00 .net

まさかμOPが関係しない
なんて考えてないよな?

373 ：ナイコンさん：2021/05/21(金) 18:23:26.62 .net

段数が多い=トランジスタが多いって
まぁそうなんだけど他の高速化するためのトラジスタ数に比べたら大したことない。
キュッシュやGPUのほうがはるかに面積を割いている。

374 ：ナイコンさん：2021/05/21(金) 18:24:22.25 .net

キャッシュ？
GPU？
そんなのと比較すんの？
暴論

375 ：ナイコンさん：2021/05/21(金) 18:27:54.48 .net

8086とV30の速度差比べればいい。V30は8080エミュレータ付きだからな。
遅くなってるか？

376 ：ナイコンさん：2021/05/21(金) 18:36:50.75 .net

インテルはデコードが面倒だからと
コンパイラ開発者に負担を押し付けるような脳足りんじゃなくてほんとよかった。

377 ：ナイコンさん：2021/05/21(金) 18:40:31.58 .net

インテルのゲルシンガーは
確かデコーダは常に負荷がかかるから設計上の難しさがある
と言ってたな
キャッシュやGPUは回路規模で性能が決まるがデコーダは違う

378 ：ナイコンさん：2021/05/21(金) 18:48:20.29 .net

CPU市場でIntelはデコーダの複雑さを理由に負けたことないし、
むしろデコーダのおかげで圧倒的勝利を収めてこれた。
複雑だからバイナリ互換捨てろというのはRISC市場かマカー市場で勝手にやってもらいたい。

379 ：ナイコンさん：2021/05/21(金) 18:52:58.73 .net

でもAtomはAndroid市場で勝てなかったんじゃないか
Atomの課題はデコーダによる消費電力増加だった
インテルの主張では全体の数%ということだったが席巻したのはARMだ

380 ：ナイコンさん：2021/05/21(金) 18:58:17.97 .net

負けたのはAndroidがARMのバイナリ縛りがあってx86が動かないんだもの。
Javaは糞遅いからまともに速度出そうとすると結局ライブラリ群はCやアセンブラが多用されてしまう。
結果ARM専用になってしまった。x86androidもまともに動くようになったのはarmエミュ積んでるからだし。

381 ：ナイコンさん：2021/05/21(金) 19:23:44.93 .net

>>372
> まさかμOPが関係しない
また誰も言ってないことを言い出したなw

382 ：ナイコンさん：2021/05/21(金) 19:26:41.89 .net

>>379
> Atomの課題はデコーダによる消費電力増加だった
とりあえずソース出してから語ろうか

383 ：ナイコンさん：2021/05/21(金) 19:36:19.56 .net

8086から使われてる省トランジスタのためにマイクロコード、高速化のためのμOP。
最初に言っとくがRISC思想とは何の関係もないからな。

384 ：ナイコンさん：2021/05/21(金) 19:46:46.44 .net

>>382
ソースも何も対ARMならそうなるだろうに

385 ：ナイコンさん：2021/05/21(金) 19:47:35.47 .net

消費電力をARM並にしたら性能もARM並になりましたとさ。

386 ：ナイコンさん：2021/05/21(金) 19:48:47.75 .net

>>380　詳しい事はよくわかんが、380に同意。

今って、昔の80x86や980ｘ0のような、資産豊富な位置にARMが居るからなんじゃないの？

387 ：ナイコンさん：2021/05/21(金) 19:49:42.48 .net

>>380
これが本当だとしたらPCの世界のx86縛りの逆をやられたのか
皮肉なもんだ

388 ：ナイコンさん：2021/05/21(金) 19:53:54.92 .net

スタート時点ではARMでしか動かないAndroidアプリは少なかったけどな
今は知らない

389 ：386：2021/05/21(金) 19:58:12.19 .net

〇　昔の80x86や680ｘ0のような
×　昔の80x86や980ｘ0のような

・・・せっかくレス番i386だったのに書き込み文を間違えた(´・ω・`)

390 ：ナイコンさん：2021/05/21(金) 20:06:17.69 .net

>>380
VM上ではCPU依存ないし用意しとけばatom泥でx86ネイティブバイナリーも動くんだが
まったくどこでそんな知識をgetしたのか妄想こしらえたのか知らんが

391 ：ナイコンさん：2021/05/21(金) 20:14:23.83 .net

>>380
Javaは重いと言えるほど遅い言語じゃねーよ！

392 ：ナイコンさん：2021/05/21(金) 20:16:49.25 .net

まだ妄想の中で生きてるんだな。ソフトとハードを切り離せるとか未だに信じてるのか。
Write once, debug anywhere.　JVMで実現できなかった夢をgoogleなら達成できると
低速エミュならともかく実機と同じ速度なんて無理なんだよ。

393 ：ナイコンさん：2021/05/21(金) 20:19:57.29 .net

Javaが不利なのはハードを叩くようなプログラムを書けないことじゃないか
ベンチではC++と大差ない
遅いと思ってる人はJITを知らないんじゃないのか

394 ：ナイコンさん：2021/05/21(金) 20:23:08.44 .net

>>384
単なるお前の妄想やんw
消費電力は増えるにしても最も大きな課題になるとは限らんぞ

395 ：ナイコンさん：2021/05/21(金) 20:26:55.95 .net

大差ないようなテストしかしてないからだろう。
そんなことが可能なら処理系依存ありまくりのC++でなくOSもJavaで書けばいい。

396 ：ナイコンさん：2021/05/21(金) 20:27:23.64 .net

>>390
まあ、いろんなCPUで動く仮想マシンを中間言語みたいにして汎用性を出す試みは昔からあるよな
Pコードとか

Java仮想マシンやら.NET Frameworkもだっけ

泥のネイティブアプリがクロックの割には重い感じなんって仮想マシンかなあ、などと思ったこともあった。

397 ：ナイコンさん：2021/05/21(金) 20:40:00.22 .net

たとえば配列アクセスね。JavaやC#は必ず範囲チェックが入る。
実行時に範囲外がアクセスされれば例外が投げられる。C/C++は何のチェックもしない。

本気で同じ速度になると思ってるのかね？

398 ：ナイコンさん：2021/05/21(金) 20:43:11.35 .net

それを言うなら、オブジェクトの生成や解放はJavaの方が速いだろう

399 ：ナイコンさん：2021/05/21(金) 20:50:54.87 .net

ARMやx86ネイティブバイナリーならUIはOS依存で遅いがGL描画や
ゴリ書きした物理エンジンなら限界近くまで速度出るよ
まあネイティブアプリかどうかはみためじゃわかんないがな

400 ：ナイコンさん：2021/05/21(金) 21:03:54.84 .net

>>398
そもそもなぜLinuxやNTのカーネル開発者よりJVM開発者のほうが速いコードが書けると思ってるんだ？

401 ：ナイコンさん：2021/05/21(金) 21:07:45.81 .net

>>398
ローカルならC++ならSPずらすだけでノーコストじゃないのか。

402 ：ナイコンさん：2021/05/21(金) 21:53:08.94 .net

>>398
androidをコンパイルすれば分かるJavacの糞さ。
Cはサクサクコンパイルが終わるのにJavaのコンパイルでは地獄が始まる。メモリ不足!!メモリ不足!!メモリ不足!!
オブジェクトの生成や解放の何が優れてるって？w

403 ：ナイコンさん：2021/05/21(金) 21:59:08.25 .net

解ってない人が珍コード書くとそうなるのかしら

404 ：ナイコンさん：2021/05/21(金) 22:17:08.14 .net

何も解ってないのはJava信者。

405 ：ナイコンさん：2021/05/21(金) 22:31:44.88 .net

おれが信者か知らんけどそういう珍トラブルは無いな信心が足りないんじゃないのw?

406 ：ナイコンさん：2021/05/21(金) 22:38:45.63 .net

このスレの住人ってアセンブラから叩き上げの人ばっかなのに、
Javaが速いとか本気で言ってる人がなんでいるの？

407 ：ナイコンさん：2021/05/21(金) 23:00:46.78 .net

>>405
googleのandroid開発者を貶す前にキミはandroidをコンパイルしたことあるのかね？

408 ：ナイコンさん：2021/05/21(金) 23:19:38.91 .net

ここは攻撃性の高いクズの集まりだな

409 ：ナイコンさん：2021/05/21(金) 23:23:30.65 .net

Javaが速いなんて言うからだろ。ここはアセンブラスレみたいなものだぞ。
バイナリそのまま読める人たちにJavaバイトコードをすらすら読めないレベルじゃ勝ち目はない。

410 ：ナイコンさん：2021/05/21(金) 23:49:18.45 .net

頭の悪い人が多いスレだなぁ
自分では頭いいと思ってるんだろうけど

411 ：ナイコンさん：2021/05/22(土) 00:19:48.35 .net

信者は信者と言われるだけあって具体例がない。
むしろ反論は具体例だらけ。マカーと同じ病だよ。

412 ：ナイコンさん：2021/05/22(土) 00:27:23.08 .net

話戻すけど可変長デコーダの実装が難しいというけど、
x86互換CPUメーカーはみな難なく実装してしまってるという事実。

413 ：ナイコンさん：2021/05/22(土) 03:12:29.43 .net

JAVAとかC++とか全然わかんねーだよ
おまいらスレのキホンにC9

414 ：ナイコンさん：2021/05/22(土) 05:55:23.50 .net

x86以外のCPUがPC市場で相手にされなかったのと同じで
ARM以外のCPUがスマホ市場で相手にされなかった
重要なのはソフトウェアの方でCPUの性能なんて二の次ということ

415 ：ナイコンさん：2021/05/22(土) 06:13:26.36 .net

スパコンのTOP500のランキングは
1位：ARM
2位：POWER
3位：POWER
4位：神威
5位：AMD EPIC
6位：Intel Xeon

1位から4位はx86以外が独占

416 ：ナイコンさん：2021/05/22(土) 06:23:51.05 .net

で、マスクの効果をスパコンで確認するんですね。

417 ：ナイコンさん：2021/05/22(土) 09:46:17.84 .net

>>412
実装が難しいんじゃなくて、処理が重いのでパイプラインの段数が多い部分なんだよ

418 ：ナイコンさん：2021/05/22(土) 09:57:27.14 .net

処理が重いと言う割にx86はintelもamdもclock辺り性能はトップクラスだという。

419 ：ナイコンさん：2021/05/22(土) 10:14:59.24 .net

>>402
JavaとJavac、実行時とコンパイル時がごっちゃになっていて何が言いたいかわからん
Cなんてコンパイル時にメモリ管理なんてしてないのでは

420 ：ナイコンさん：2021/05/22(土) 12:14:14.49 .net

実機は滅んだけどほぼすべてのアプリ開発は仮想化支援の効いたx86版のandroidエミュ上で
制作されてるんだがな
CPU依存はしてないってのに素人が知ったかぶっこいてるのがなんともまあ昔のPC板だからか

421 ：ナイコンさん：2021/05/22(土) 21:35:51.12 .net

何言ってるかさっぱり分からんからとんでもない勘違いしてると思う。
スレチだからJavaの開発スレでマウンティングしてきて。

422 ：ナイコンさん：2021/05/22(土) 21:38:27.42 .net

>>420
Androidの実機を接続してテスト＆デバッグしてるに決まってるだろ？
今時、Android Studioのエミュ使ってる人なんているの？

423 ：ナイコンさん：2021/05/22(土) 21:39:29.34 .net

x86の各命令のレイテンシもスループットもCPUではトップクラスだから、
デコード処理が重いことは性能のボトルネックにはなっておらず、
パイプラインで完全に隠蔽されているということ。

424 ：ナイコンさん：2021/05/22(土) 21:41:45.56 .net

昔のPC板において、Sunは訴訟でMSに勝ち、MSはWindowsからJVMを削除した。
そしてJavaは市場から消えた。ここままでが昔のPCで扱っていい範囲だぞ。

425 ：ナイコンさん：2021/05/22(土) 21:57:09.73 .net

スレチな書き込みの方が多いよなー

426 ：ナイコンさん：2021/05/23(日) 09:48:14.92 .net

>>423
そりゃ、性能上のコストは開発費と製造費を押し上げてるだけで、そこさえ克服したら最終性能を下げる訳じゃないからな

ただ、ARMなどRISCCPUに比べてパイプラインの段数が深くなりやすい傾向があって性能向上のネックだったのはプレスコットの失敗を見れば分かるだろ
デコード回りの部分の段数が多くて、全体の段数が、同程度のRISCより三割ぐらい多くなってるから、どうしても段数が多くなるんだよ

427 ：ナイコンさん：2021/05/23(日) 10:19:05.54 .net

パイプラインの段数増やせる、単段ごとの処理を軽く分解できるデコードなら、高速化の妨げにならない良いデコードって事
まあマイクロコードのが元々だから当然だが

428 ：ナイコンさん：2021/05/23(日) 10:43:54.01 .net

M1 3GHzとi7 5GHzで勝ち負け言ってる時点でもうね

429 ：ナイコンさん：2021/05/23(日) 16:10:24.09 .net

8086が最上位CPUのスレでJavaとかAndroidとかパイプラインとか完全にスレ違いだな

430 ：ナイコンさん：2021/05/23(日) 16:44:47.42 .net

その「8086」でさえ他は8ビットなのに16ビットなので違和感あるけど。

それはそうと6502で「VisiCalc」やファミコンアプリができたけど、コツは何だろう

431 ：ナイコンさん：2021/05/23(日) 17:16:41.86 .net

少ししか触ってないが小物書くならZ80より楽だなゼロページがレジスタ代わりになって
予想外だがゼロページをループカウンタに使うときレジスタに読まなくても分岐できたり

432 ：ナイコンさん：2021/05/23(日) 17:35:39.98 .net

コツはそうですね。さっさと諦めてSweet16を使うことですよ。

433 ：ナイコンさん：2021/05/23(日) 17:47:55.99 .net

小物書くなら

規模があると途端に面倒くさいことになるということです。
その壁はワークエリア256バイト。16bitレジスタがないため常に8bitの壁が付きまとう。
アクションゲームは得意だがシミュレーションゲームは苦手。

434 ：ナイコンさん：2021/05/23(日) 18:05:52.35 .net

んー使い込んでないからなんとも言えんけどゼロペに仮でIX,IY,IZと名付けた16ビットテーブル3つ
でも用意しとけば上手いこと回せないかしらね

435 ：ナイコンさん：2021/05/23(日) 18:52:15.72 .net

Z80より楽なら期待できそうです。また「Sweet16」が「Apple II」のBASICに
含まれる16ビットCPUエミュレータとは今日、名称を含めて初めて知りました。
ゲームを作る予定はないですがファミコンのゲームは安価に入手できますので
ゲームソフトの改造を楽しんでみようかと目論でいます。今更ゲームをすることは
飽き飽きしてますので改造することを楽しむ感じです。尚、売ったりはしません。

因みにコードを書いてる方はアセンブラでは何を使ってますか？

436 ：ナイコンさん：2021/05/23(日) 19:17:52.66 .net

対象の機械で動くものを使う他ないんじゃない？
CPUの種類見て機械を選ぶような時代ではもうない

437 ：ナイコンさん：2021/05/23(日) 19:36:22.14 .net

「WLA DX」なら6502以外でも使えると聞いていて「cc65」は6502限定と聞いてます。
使い易く、なるべくオープンソースがあればと考えて、質問しました。

438 ：ナイコンさん：2021/05/25(火) 00:01:07.14 .net

レジスタの数的に6502ハンデありすぎちゃいますのん

439 ：ナイコンさん：2021/05/25(火) 00:07:35.98 .net

6502がZ80より楽になることはないよな

440 ：ナイコンさん：2021/05/25(火) 00:22:27.26 .net

6502はABS,XとABS,Yの動作が絶妙
6800の三倍速いというのも納得というか16bitレジスタ持ってるくせに間接アドレッシングと変わらん6800が情けない
Z80は一瞬だけ速い直線番長だしクセは強いが6502は慣れれば最強

441 ：ナイコンさん：2021/05/25(火) 00:28:11.62 .net

6502でZ80におけるCP/Mのようなベースとなる環境は何ですかね？

442 ：ナイコンさん：2021/05/25(火) 00:35:26.81 .net

GEOS？

443 ：ナイコンさん：2021/05/25(火) 14:44:20.85 .net

「GEOS」はコモドール64（MPU：MOS 6510） で採用されたOSなので違うのではと。
6502用と言うなら「GeckOS-V2（ヤモリ）」と言う噂もある、よく知らんけど説明は下。
ヤモリは、マルチタスクであるオペレーティングシステム用のMOS 6502などの互換
プロセッサMOS 6510。 GeckOSオペレーティングシステムは、6502アーキテクチャに
Unixライクなオペレーティングシステムを実装するための数少ない成功した試みの1つとか。

8ビットでUnixライクなOSと言えば「OS-9」的かなと、よく知らんけど。

444 ：ナイコンさん：2021/05/25(火) 15:01:54.95 .net

>>443
Apple II用GEOSも有るんでコモドール64に標準採用されただけで6510専用OSでは無いよ

445 ：ナイコンさん：2021/05/25(火) 15:14:24.81 .net

コモドールは70年代末のPET時代からCMB-DOS。GPIBがFDDインタフェースだった。
Atari-DOSも70年代末から。Atari-DOSの開発者はPaul Laughton。彼はApple][の
DISK-IIのDOS3.1の開発者でもある。Apple][のDOS番号は機能改定じゃなくて
単にリリス順番。3.3は33回目のリリスに過ぎないとか。c64とかのGEOSは GUI有だったかな
LisaやMacに先んじていたのでMSやDRIをルック＆フィールで訴えたAppleもcommodore相手に
訴訟を起こすことはなかった。とか言われているね。

446 ：ナイコンさん：2021/05/25(火) 16:03:05.28 .net

6502って8080やZ80、6800のような周辺ICってあったのかな
6800のがそのまま使えた？

447 ：ナイコンさん：2021/05/25(火) 17:57:42.68 .net

>>444
そうなんですか、失礼しました。

>>446
ACIA(6850)は6800SBCの周辺ICとして使われたけど6502でも使えるのでは。
最近は別な方が6502SBCの回路図を公開してくれたサイトがあるけど使ってる。
「W65C816も動作する6502基板を製作してみました」で検索して下さい。

448 ：ナイコンさん：2021/05/25(火) 18:37:26.49 .net

6502の設計者たちはモトローラで6800シリーズを開発していたエンジニアだからね。
6502シリーズで6800周辺が利用できるのは当然自然。

449 ：ナイコンさん：2021/05/25(火) 18:48:41.06 .net

6800開発チームのリーダー格はぺドルとメンシュ。6800のマーケティングで
齟齬があってモトローラを退社してモステクノロジーを設立。それを金に任せて
買収したのがコモドールのトラミエル。買収時ぺドルは残ったがメンシュは退社。
WDC社を設立して65186やCMOS版の6502などでAppleと蜜月したそうな。

450 ：ナイコンさん：2021/05/25(火) 18:52:42.15 .net

スマホのモトローラはGoogleに買収された後ブランドを中華のレノボが買ったんだってね。
OCNがg30とかいうモトローラのスマホを1円売りしていたのでポチったヨン

451 ：ナイコンさん：2021/05/25(火) 18:55:29.32 .net

65186 -> 65816

452 ：ナイコンさん：2021/05/25(火) 18:59:09.43 .net

結論:　6502に開発環境を構築できるパワーはない。

453 ：ナイコンさん：2021/05/25(火) 19:53:39.88 .net

ファミコンのゲームを製作した時もPC-98等でクロス開発したと聞くから
6502でセルフ開発はしてないし、まして今更セルフ開発はしないと思う。
「cc65」と言ってもクロス開発が前提なので動作環境を問題にしてるのでは。
ゲームをセルフ開発できると半ば騙されたオタクが頑張った例はあるらしいけど。

454 ：ナイコンさん：2021/05/25(火) 20:07:34.16 .net

6502は高速なエディタの実装とか苦手そう。

455 ：ナイコンさん：2021/05/25(火) 23:09:07.33 .net

motorolaのスマホは作りは良かったが、AER対応端末(発売から5年間、90日以内のアップデート保障)の筈なのに
2年でアップデートを反故にしてくれたので、もう二度と買わんうちの敷居は跨がせないクソブランドに認定

車載用のシガーソケットアダプタでモトローラのロゴが光るやつがお気に入りで使っていたけど
mini-Bとmicro-Bで出力も700mAくらいしか無いから、さすがにこのご時世にはおつらい
USB PDとは言わないまでも、2A程度の出力でtype-Cのものがあれば良いのだが…

456 ：ナイコンさん：2021/05/26(水) 00:24:30.66 .net

誤爆にもほどがあるな。

457 ：ナイコンさん：2021/05/26(水) 06:51:11.99 .net

>>441
DOS65というOSがあったようです。
開発ツールが充実しているかは不明。

458 ：ナイコンさん：2021/05/26(水) 10:29:02.23 .net

>>454
文字列の配列なら得意分野だけど
構造体の配列は全体のサイズが256バイト超えるとZ80並に難しくなる

459 ：ナイコンさん：2021/05/26(水) 10:53:46.84 .net

「6502用のアセンブラ、CA65 は CC65パッケージの一部として配布されます」
と記述があるから Linux にインストールしてオプションを確認してみました。

$ ca65 --help
Usage: ca65 [options] file
Short options:
-D name[=value] Define a symbol
-I dir Set an include directory search path
-U Mark unresolved symbols as import
-V Print the assembler version
-W n Set warning level n
-d Debug mode
-g Add debug info to object file
-h Help (this text)
-i Ignore case of symbols
-l name Create a listing file if assembly was ok
-mm model Set the memory model
-o name Name the output file
-s Enable smart mode
-t sys Set the target system
-v Increase verbosity

460 ：ナイコンさん：2021/05/26(水) 10:55:33.85 .net

＜続き＞
Long options:
--auto-import Mark unresolved symbols as import
--bin-include-dir dir Set a search path for binary includes
--cpu type Set cpu type
--create-dep name Create a make dependency file
--create-full-dep name Create a full make dependency file
--debug Debug mode
--debug-info Add debug info to object file
--feature name Set an emulation feature
--help Help (this text)
--ignore-case Ignore case of symbols
--include-dir dir Set an include directory search path
--large-alignment Don't warn about large alignments
--listing name Create a listing file if assembly was ok
--list-bytes n Maximum number of bytes per listing line
--memory-model model Set the memory model
--pagelength n Set the page length for the listing
--relax-checks Relax some checks (see docs)
--smart Enable smart mode
--target sys Set the target system
--verbose Increase verbosity
--version Print the assembler version

461 ：ナイコンさん：2021/05/26(水) 11:02:49.99 .net

高速なエディタに比べれば、GUI-OSなんて簡単なものなの？

462 ：ナイコンさん：2021/05/26(水) 11:24:26.90 .net

続けて「6502アセンブル/逆アセンブル」で検索して
使い方があるサイトみつけ、内容をなぞってみたら
何とかなりそうと感触を得ました。

463 ：ナイコンさん：2021/05/26(水) 20:41:56.12 .net

ProDOSをApple II以外に移植した人類はいないのか

464 ：ナイコンさん：2021/05/27(木) 06:47:37.16 .net

6502はstaticなメモリ配置はいいが、アドレスが動的に変わるような用途では途端に面倒になる感じ。
だからOS的な用途には向かないかも。

465 ：ナイコンさん：2021/05/27(木) 13:54:20.90 .net

6502を使ったPCとしては「Apple II」が有名ですが、他CPU（Z80や6809等）を
動作させる拡張カードもあったと言うので「Apple II」は「FM-7」の先駆けかなと。
ただ「6502→6809」だと意義がありますが「6809→6502」だと疑問が残ります。
もっともCPUの換装となると話は別で、どのような仕組みだったのかと言う興味はあります。

466 ：ナイコンさん：2021/05/27(木) 15:46:14.97 .net

Z80はstaticなメモリ配置はいいが、アドレスが動的に変わるような用途では途端に面倒になる感じ。
だからOS的な用途には向かないかも。

467 ：ナイコンさん：2021/05/27(木) 16:07:12.56 .net

以上から、6809をお勧めする

468 ：ナイコンさん：2021/05/27(木) 16:25:08.14 .net

以上もイカも、6809しか判らないタコ助だけどZ80にCP/Mがあり、6502は下のPC（ゲーム機）で使われてるし。
VIC20
C16/C116 and Plus/4
C64
C128
CBM 510 (aka P500)
the 600/700 family
newer PET machines (not 2001).

the Apple ][+ and successors.
the Atari 8-bit machines.
the Atari 2600 console.
the Atari 5200 console.
GEOS for the C64, C128 and Apple //e.
the Bit Corporation Gamate console.
the NEC PC-Engine (aka TurboGrafx-16) console.
the Nintendo Entertainment System (NES) console.
the Watara Supervision console.
the VTech Creativision console.
the Oric Atmos.
the Oric Telestrat.
the Lynx console.
the Ohio Scientific Challenger 1P.
the Commander X16.

469 ：ナイコンさん：2021/05/27(木) 17:22:22.13 .net

>>464,466
そんなこと言ってたら、68000でさえ16ビットのモデルのうちはリロケータブルなソフト書くには多少なりとも余分な手間が必要だったわけだが

だから、例えばx68000とかでは、絶対アドレス指定してる部分を仮アドレスとしておいて、DOSがロード時にロードする位置と足しあわせて実行アドレスに書き換えながらロードしてた
たぶん、MS-DOSのexeと同じような?

逆に言えば、DOS側で多少余分な手間をかけてやれば、Z80とかでも読み込みアドレスを固定にしないで任意アドレスに変更できる仕組みを作れてたのでは?

470 ：ナイコンさん：2021/05/27(木) 18:29:04.63 .net

もちろんできなくもないが
コストかけてまでやるメリットがなかった

471 ：ナイコンさん：2021/05/27(木) 19:36:01.49 .net

movcpm

472 ：ナイコンさん：2021/05/27(木) 19:54:57.18 .net

スタックフレーム、mallocのようなデータの位置が実行時に決まることと、
コードがリロケータブルに書けることとは分けてもらわないと。
チープなCPUは前者の実装すら面倒だねって話。

473 ：ナイコンさん：2021/05/27(木) 20:27:01.30 .net

本来、MMUとOSがやるべきメモリー管理を、アプリケーションでやる命令セットってな歪んだ一時的な仇花だったような

474 ：ナイコンさん：2021/05/27(木) 20:29:43.68 .net

そりゃまあ、ワークメモリとかスタックがゼロページに固定されてるとかだと、色々と厳しいな

475 ：ナイコンさん：2021/05/27(木) 21:02:09.31 .net

>>469
> そんなこと言ってたら、68000でさえ16ビットのモデルのうちはリロケータブルなソフト書くには多少なりとも余分な手間が必要だったわけだが
OS-9/68000 とかでソフト作ってたけど言うほど手間はかからんかったように思う

476 ：ナイコンさん：2021/05/27(木) 21:10:00.26 .net

68000って、ディスプレースメントが16ビット幅で、レジスタの値から±32KBまでしか指定できないから、
完全なリロケータブルにするときはアドレスを演算してから指定しないといけないだろ
相対分岐も16ビット範囲だけしか使えないし

小さいプログラムならともかく、大きなやつを書くときは単純に書くわけにはいかんじゃん、多少の余分な手間

余分な手間が多少ですむだけ強力とは言えるが

477 ：ナイコンさん：2021/05/27(木) 21:23:20.14 .net

＞完全なリロケータブルにするときはアドレスを演算してから指定

つまりやれば出来るってこと
メガ単位のリロケータブルコードをそのようにして書いたことがあるが特に困難はなかった

478 ：ナイコンさん：2021/05/27(木) 21:30:01.62 .net

68000でメガ単位のプログラムねぇ…

479 ：ナイコンさん：2021/05/27(木) 21:31:58.32 .net

なぜ6502の話が68000の話になるのだ。

480 ：ナイコンさん：2021/05/28(金) 00:11:20.65 .net

大半の得意技が脱線だからではないかな、ついでにRISCよりはまだマシかなと。

481 ：ナイコンさん：2021/05/28(金) 00:16:31.89 .net

それとスレタイにある「8086」は「8080」の間違いではないかとの指摘がある。
「8086」は違和感大有り。脱線は阻止できないけどスレタイだけでも修正できないかな。

482 ：ナイコンさん：2021/05/28(金) 00:33:23.38 .net

んでも、8080 v.s. Z80って意味有るか？

483 ：ナイコンさん：2021/05/28(金) 03:49:04.75 .net

書かれている順番から想像すると
最初のスレ主は8086最高！といいたかったんじゃない？

484 ：ナイコンさん：2021/05/28(金) 05:49:23.16 .net

> 8086(8088)・Z80・6809・6502のうち、どのCPU(MPU)が優れているか議論するスレッドです。
って書いてあるから誤記ではないと思う
まあ8080(8008)の誤記の可能性もあるけど…

485 ：ナイコンさん：2021/05/28(金) 08:56:47.08 .net

>>474
32bitに拡張して4GBのゼロページにすれば問題解決やな

486 ：ナイコンさん：2021/05/28(金) 10:23:48.28 .net

16bitジレスタあり 8086、Z80、6809
16bit演算可能 8086、Z80、6809

違和感、浮いてるのはむしろ6502だけである。

487 ：ナイコンさん：2021/05/28(金) 12:09:40.23 .net

アドレス計算のための16bit演算をいちいち命令並べて実行しなきゃならない80系が気持ち悪い
経営最優先で未完成のゲテモノを世に出した迷惑intel

488 ：ナイコンさん：2021/05/28(金) 12:27:11.37 .net

気持ち悪いと思うのは勝手だが
アドレシングモードのないプロセッサが優秀だと思ってる奴は居ないんだし目の敵にする意味がわからん

489 ：ナイコンさん：2021/05/28(金) 12:29:08.52 .net

>>485
じゃなくて、ワークエリアとして使うゼロページの部分が固定アドレスのままだとリロケータブルじゃなくないか?

他のプログラムとバッティングしないように頻繁に待避させるとかするのかな?

490 ：ナイコンさん：2021/05/28(金) 14:37:45.21 .net

>>486
プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
なのでCPU(MPU)を意識する際に他の8ビットと同列に「8086」を語るには違和感が残ります。
また、Z80も16bit演算可能と言ってますがSUBはないので、説得力が弱い印象を受けます。

ただ、Z80にしても6502にしてもCPU(MPU)の制約があっても開発環境で補うことができたと思う。
当時は日本に6502を使うPCがほとんど存在せず性能が判らなかったけど意外と使えたのでは。
何より実用的には「VisiCalc」が存在して、ゲーム機としては「ファミコン」の成功があります。
下で「Z80 vs 6502」の比較をユーザーとして語ってる人がいます。 尚、自分は6809ユーザーです。
ttps://www.wizforest.com/tech/Z80vs6502/index.html

491 ：ナイコンさん：2021/05/28(金) 15:02:40.30 .net

ヤマハのYISに使われた6502はゼロページが複数あったとか
実装方法は謎だがAm9511やZ8001やハードウェア直線発生とかなんとも凄まじいマシンである

492 ：ナイコンさん：2021/05/28(金) 15:06:06.04 .net

ゼロページをCPU内蔵のローカルメモリなりにしてバンク切り替えしたらいいんでは

内蔵じゃなく外部メモリでもバンク切り替えなら複数のゼロページは持てるけど、それ以外の部分のメモリと別枠でバンク切り替えが要るから、内蔵の方が楽だと思う

493 ：ナイコンさん：2021/05/28(金) 16:44:24.09 .net

>>490
> なのでCPU(MPU)を意識する際に他の8ビットと同列に「8086」を語るには違和感が残ります。
お前8bit CPUでアセンブラ使ったこと無いだろ
8bit CPUで済む範囲なら同列どころか8086の方が全然楽だぞ
64KB超えると面倒になるけどそもそも8bit CPUだと外部ハード無しで64KB超えられないし

494 ：ナイコンさん：2021/05/28(金) 17:40:39.81 .net

>>492
全てのメモリを汎用レジスタとして使えるようにしようTMS9900みたいにね

495 ：ナイコンさん：2021/05/28(金) 19:12:27.37 .net

>>493
6809ですが使ったことはあります。尚、8bitCPUのアセンブラでも8086機で
クロス開発した方が楽とは考えますが、システム的に8bitで対応できるのに
何故わざわざ回路が複雑になる16ビットにするのかと、疑問が深まりました。
なので、どのようなシステムで8086を使ったのでしょう。尚、8bitCPUで
対応できない時は8086を使うとして「C言語」コンパイラが効率的と考えます。
勿論、8bitCPUでも可能なら「C言語」コンパイラが効率的と考えますけど。
因みに下は上手く表示できるか否かは判りませんが自分のコード例です。

CLRA
STA MFDA2
STA MFDA3
COMA
STA MFDA6
LDA MFDA0
LDA #$83
STA MFDA3
LDA #$2E
STA MFDA5
RTS

496 ：ナイコンさん：2021/05/28(金) 20:15:11.60 .net

>>495
何を言いたいのかさっぱりわからんがとりあえず
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
が脳内でないなら実例書いてくれ

497 ：ナイコンさん：2021/05/28(金) 21:37:46.64 .net

>>495
80年代前半で8086を積極採用していた業界は半導体製造装置とか
三軸同時制御的なアームロボットメーカーとかだね。東京エレクトロンとか
富士通ファナックとか。東エレはインテルの代理店もやっていたね。
ファクトリーオートメーションの世界では年追うごとに要求仕様が複雑化
高速化ネットワーク化していたから16bit移行は早かった。PL/MコンパイラとかICEとか。
かいはつかんきょうもよかった。対して68000やz8000にはマトモなICEが無かった。
組み込み業界ではムリぽだったみたいね。

制御モンでもパソコン用のプリンターとかの小型スタンドアロン機器は
は普通4/8bitCPUだった。ビデオデッキやエアコンとかは4bit。

498 ：ナイコンさん：2021/05/28(金) 21:50:56.67 .net

>>496
趣旨としては8bitCPUならアセンブラでも失敗せずに開発が可能と言うことと
16ビットでアセンブラなら開発効率は悪いし失敗の可能性が高くなると言うことです。
16ビット以上ならCPUを意識しない、高級言語を使うことが賢いのでないかと言うことです。

尚、失敗談は脳内ではなく実例で聞いていますが、先ずは貴方の下の疑惑に応えましたから
＞お前8bit CPUでアセンブラ使ったこと無いだろ

次に順序としては貴方が本当に「8086」をアセンブラで使っていたことの明示が先ではないなと。
貴方のレスかは特定できませんがZ80で16bit演算可能と言ったことで「えー、減算はないけど」と
逆に貴方にZ80でさえ本当にアセンブラを使っていたのか疑惑が湧いています。因みに下が質問です。
1）何故わざわざ回路が複雑になるのに16ビットにするのか？
2）どのようなシステムで8086用のアセンブラを使ったのでしょうか？

499 ：ナイコンさん：2021/05/28(金) 21:52:25.24 .net

> Z80も16bit演算可能と言ってますがSUBはないので、説得力が弱い印象を受けます。
SBC、DECあるだろう。6502にadd命令がないから8bit演算できないと言ってるようなもの。

500 ：ナイコンさん：2021/05/28(金) 22:07:34.78 .net

1)速度が必要だから
2)速度が必要なシステムで

486ですら速度に対する要求は満たされておらず、エディタですらフルアセンブラであることが売り文句になった。
vzはめちゃくちゃ売れた。

501 ：ナイコンさん：2021/05/28(金) 22:10:52.53 .net

8086ならCでも十分高速だから
アセンブラ派が少なくなっただけだろ？
使いにくいと言うか、Z80のアセンブラよりはずっと楽

502 ：ナイコンさん：2021/05/28(金) 22:24:31.11 .net

> 8086ならCでも十分高速だから
BASICと比べたらな。

503 ：ナイコンさん：2021/05/28(金) 22:34:08.52 .net

>>497
自分が書いてるうち応えてくれたので、先ずは応えます。
1）MSがアクセスを販売する前後に某大手メーカーが類似品を「8086」ベースのマクロアセンブラで開発して失敗とか。
自分は失敗後に配属され「C言語」で完了していたので「8086」ベースのマクロアセンブラの失敗を先輩が嘲笑してました。
2）「Z80」ベースかも知れないけど後に任天堂の社長になる故岩田氏のC言語を使う決断で企画を成功に導いたとか。
ttps://www.4gamer.net/games/999/G999905/20151225009/

因みに1980年代半ばならパソコン用のプリンターでは表示用にセグメントではないリニアな空間が必要なので
「68000」が使われることもありました。1990年頃にはインテルのリニアなCPUが使われて開発に参画しました。

それで貴方が実際に製作に関わったシステムは何ですか？

504 ：ナイコンさん：2021/05/28(金) 22:42:47.25 .net

アイレムのM72がV30使ってたけどな
R-TYPEとかのシステム基板で当然アセンブラ使ってたはず
自分はMS-DOSでアセンブラのソフトをいくつか書いたけど、Z80や6800、6502に比べると書きやすいよ
まあ68000よりは落ちるけど
Lotus123はアセンブラだったはずだし日本ではVzもあったし、TSRはCでも書けたけどメモリ節約のために普通はアセンブラだった
デバイスドライバもFEP以外はアセンブラが多かったと思う

505 ：ナイコンさん：2021/05/28(金) 22:51:09.66 .net

>>503
> 1）MSがアクセスを販売する前後に某大手メーカーが類似品を「8086」ベースのマクロアセンブラで開発して失敗とか。
それZ80なら成功してたのか？
8bit時代とは規模の違うものを出してきて8086のアセンブラは効率悪い言ってるだけにしか見えない

> それで貴方が実際に製作に関わったシステムは何ですか？
社内の設備屋だったから結構CPUは自分の好みで決めれたからHD6301, MC6809, MC68000, i80186, MC68020とか使ってたよ
6809まではフルアセンブラ、68000はForthを自力で実装してその上でアプリを書いてた
80186以降は基本CだけどブートとかI/O周りはアセンブラ

506 ：ナイコンさん：2021/05/28(金) 22:59:09.64 .net

>>499
「SBC」や「DEC」を使って16bit数値から16bit数値を引く減算のアセンブラコードを明示して下さい。

507 ：ナイコンさん：2021/05/28(金) 23:00:35.46 .net

>>503
アクセスって事はデータベースなんだろうけどdBASE IIはアセンブラだったはず
dBASE IIIでC言語で書き直されて性能低下したという話だったような
ようするに成功するか失敗するかは開発者の技術力の問題なだけで嘲笑したという先輩もたいした事はないですな
8086出始めの頃はメモリも高かったし速度も必要な場合、普通にアセンブラを使ってたはず
C言語にしても性能が良くなるまでには時間がかかった
繰り返しますが8086はコードデータがそれぞれ64Kに収まるプログラムであれば8bitCPUより書きやすいです

508 ：ナイコンさん：2021/05/28(金) 23:02:16.39 .net

アセンブラコードを多く含んたWindows95が大成功してる時点でなあ。
この人は一体なにが言いたいのだろう。ADC、SBC、DECの使い方知らないとかアセンブラど素人じゃん。

509 ：ナイコンさん：2021/05/28(金) 23:10:00.57 .net

キャリーフラグ知らなかったMIPS君かも

510 ：ナイコンさん：2021/05/28(金) 23:12:08.05 .net

>>503
岩田氏の記事ちゃんと読んでる？ゲームボーイのアセンブラソースをNintendo64用のC言語のソースにコンバートしたって話だよ
8086全然関係ないんだけど
あと組み込みでは意外と8086使われてるんだよね
そりゃ画像処理が必要なプリンタとかでは採用されないけど
適材適所って言葉知ってる？

511 ：ナイコンさん：2021/05/28(金) 23:18:24.32 .net

アセンブラソースをCにコンバートってこのスレの住人クラスならすげーって感じにはならないと思うが。
z80ならバイナリ直読みで解析する人も多いんじゃないかな。

512 ：ナイコンさん：2021/05/28(金) 23:19:14.62 .net

>>506
Z80のSBC命令だと16ビット値を入れたペアレジスタ（レジスタペア）の引き算ができるんだから、あらかじめキャリフラグをリセットしとけば普通に引き算できるだろ?

513 ：ナイコンさん：2021/05/28(金) 23:23:14.58 .net

>>504
なるほど。「68000」に思入れがあるのか、実際に使いやすいのかは判りませんが
このレスは納得しました。

>>505
＞それZ80なら成功してたのか？
意図が判りかねます。MSがアクセス販売する頃に類似品でZ80ではメモリ足りなすぎなので。
それで16bitになる訳ですがアセンブラで失敗したと言う事実を例示したまでです。
ともあれ、貴方の話が本当なら貴方は比較的優秀なのではと。

しかし、その貴方も8bitまでならアセンブラで、16bit以降は「C言語」ではないにしても
ハードとのインターフェース以外では高級言語を使っていたと言うことになります。

514 ：ナイコンさん：2021/05/28(金) 23:30:52.47 .net

いやだから8086で普通にアセンブラでかかれた大きめのソフトの例をいくつもあげてるんだけど
自分も色々なCPUでアセンブラでかいてきたけど8086は書きやすい部類にはいるよ
だから8086でアセンブラで書くのががハードルが高いってのはない
データベース類似で失敗したのは単に技術力がないだけ
あなたも書き込みみてると技術力あるとは思えないけどね

515 ：ナイコンさん：2021/05/28(金) 23:34:19.71 .net

マーケティング上の成否と開発言語を結びつけようとしてるのかな？
z80vs6809しかり、x86vs68kしかり、VHSベータ戦争しかり、DVD戦争しかり。

性能の違いが戦力の決定的差ではないということを坊やに教えねばならんな。

516 ：ナイコンさん：2021/05/28(金) 23:37:15.44 .net

貧乏システムハウスに転職してターボアセンブラのEXEファイルをROM化したなぁ
ミニコンのアセンブラソースを元にした改修だったから何とかなったけど
EXEファイルの解析なんてどうやったんだか完全に記憶がない

517 ：ナイコンさん：2021/05/28(金) 23:40:52.72 .net

>>508
商業的にはWindows95は大成功したかも知れないが、落ちまくって酷いと言う話は耳に入らなかった？

>>510
最後まで読んだかな。君は自信家みたいだけど自分の失敗を他人のせいにしたことがあるのではと？

HAL研究所の三津原氏が下のように言ってるけど、MOTHER2は「スーパーファミコン」が最初じゃないのか？
　あと，岩田さんの指示で印象的だったのは，C言語を使う決断をしたことでしょう。
　当時の一般的なゲーム開発はアセンブラで行っていたのですが，開発期間も長いしデバッグも大変だったんです。
　だから，C言語で作ったほうが開発速度が速くなる（MOTHER2のような，大規模なRPGの場合にはとくに）という確信が
　岩田さんの中にはあったようでした。

518 ：ナイコンさん：2021/05/28(金) 23:46:42.69 .net

C89で標準化も終わった90年代にアセンブラからC言語で開発しようという判断なんて普通すぎる話だが
あんたの論点がさっぱり分からん。

519 ：ナイコンさん：2021/05/28(金) 23:51:52.02 .net

>>517
あー最後まで読んでなかったすまんすまん
で、それと8086のアセンブラがハードルが高いのとどういう関係があるの？
あとWindows95も使ってたけど言われるほど落ちたりしなかったよ
デバイスドライバとかにも影響されるし人によるとしか言いようがない
そりゃNT系のカーネルよりは安定しなかったけど

520 ：ナイコンさん：2021/05/29(土) 00:17:11.16 .net

>>518
だから、君のような技術的に優秀な人が8086を駆使できれば値があったことは認めるにしても
話の始まりは、そもそも機能が上の「8086」を他のCPUと同列に語ることに違和感がある、と言う事。
　　
>>519
自分の間違いは「すまんすまん」で済ます、ちゃっかり者ですか。君のような人は今後を注意して行きます。

521 ：ナイコンさん：2021/05/29(土) 00:33:46.55 .net

>>514
＞あなたも書き込みみてると技術力あるとは思えないけどね
そうかも知れないが、ただし君が絶対正しいと言う訳でもあるまいにと。

>>519
＞あとWindows95も使ってたけど言われるほど落ちたりしなかったよ
その局面と頻度が問題なるかなと。
1）そもそもが16ビットと32ビットのハイブリッドの起因（GDIだったか？）でメモリリークで落るとか
2）途中まで作ったVBアプリで更にカスタムコントロールの貼りつけで落るとか（一旦分離して再結合でクリア）
3）ウィンドウハンドルのないコントロールを整理するためにアプリ終了後に落るとか

とにかくメモリ管理の問題が酷かった、今でも名残がある感じ、ローカライズとかも。

522 ：ナイコンさん：2021/05/29(土) 00:35:19.35 .net

8086が高機能だなんて照れますな。後発の6809君に悪いですよ。

523 ：ナイコンさん：2021/05/29(土) 02:40:19.25 .net

自称6809使いがZ80のSBC、DECの使い方が分からないという謎

524 ：ナイコンさん：2021/05/29(土) 05:09:46.21 .net

>>520
> 話の始まりは、そもそも機能が上の「8086」を他のCPUと同列に語ることに違和感がある、と言う事。
ならはじめからそう書いてくれ

> プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
だとどう見ても8086はアセンブラでは開発しづらいクソCPUと言ってるように見える

> 自分の間違いは「すまんすまん」で済ます、ちゃっかり者ですか。
まあこれ見る限り煽る気満々なんだろうけどそこまで言うならこんな意味不明な文章書いてたら失笑されるだけだぞw
> 君のような人は今後を注意して行きます。

525 ：ナイコンさん：2021/05/29(土) 06:29:52.11 .net

互換性重視で拡張された8086より
6502のゼロページアドレッシング使いこなすほうが普通に難しい。

526 ：ナイコンさん：2021/05/29(土) 08:19:39.16 .net

6800のゼロページの高速化改良なんだから、6800を使いこなしてる人が使うのが簡単か難しいかでしょ
8080を使いこなしてる人が互換性有る8086を使うのと比較してどうするのよ

527 ：ナイコンさん：2021/05/29(土) 08:50:37.64 .net

6502は6800の高速改良というよりさらにトランジスタ削るために
徹底的にチープ化した結果の完全8bit縛りであって16bitレジスタ持ってる6800のノウハウは役に立たない。
そもそも6800機がないので6800熟知してる奴がまずいない。

528 ：ナイコンさん：2021/05/29(土) 12:07:58.60 .net

ゼロページと似たようなのが、組み込み用の8ビットCPUで広く採用されてるみたいだし、わりと便利だったんじゃないの

昔のSHARPのポケコンのカスタムCPUとか、マイクロチップ社のPICとかにも使ってたでしょ？

529 ：ナイコンさん：2021/05/29(土) 12:44:21.76 .net

>>524
君は捻くれてるのか？ 話の発端が、「8086」と「8080」の比較（>>481）で
「8080」なら他の3種類のCPU（MPU）とほぼ同性能だけど16ビットの「8086」では
性能が違い過ぎて、どのCPU(MPU)が優れているかの議論は無駄でしょ、って趣旨。
ただ使い方の例を明示して「8086」で実際にアセンブラ使った話は面白かった。

尚、煽る気は微塵もない。「煽り」と言って自分の勘違いを正当化しないで貰いたい。
他人は見下すし、自分の間違いは「すまんすまん」では上から目線で何様なんだろうな。

481ナイコンさん2021/05/28(金) 00:16:31.89
それとスレタイにある「8086」は「8080」の間違いではないかとの指摘がある。
「8086」は違和感大有り。脱線は阻止できないけどスレタイだけでも修正できないかな。

530 ：520：2021/05/29(土) 12:54:08.49 .net

追伸
煽る気は微塵もなかったが自分の間違いには寛容で余りに尊大な態度に
一言嫌味を言いたくなったことは認める。ギリシャ文字の人を連想した。

531 ：ナイコンさん：2021/05/29(土) 13:02:51.77 .net

>>528
MELPS740ファミリって素の6502上位互換な組み込みCPUのベストセラーもあるしな
ゼロページ分のRAMをチップ内に内蔵してたりして、
レジスタのように使うと言うよりレジスタそのものになってたりするがバイナリ互換で使える

532 ：ナイコンさん：2021/05/29(土) 13:51:04.57 .net

>>507
初代8801の頃に売れていた日本語ワープロの文筆は最初はテープ版。
ver2がDISK版。どっちもBASIC記述だった。次版は機械語版で出す。
とアナウンスしていて開発停滞でウダウダしている内に倒産。
失笑モノだったっすね。BASICと機械語の間にはポインタという小川が
あるけれど、それすら渡れないとかね

533 ：ナイコンさん：2021/05/29(土) 14:04:33.09 .net

>>529
8080は8224とか8228とか必須で単独使用は面倒。それ故の8085。ところが
DRAM制御を8080/85で行うのは面倒。z80はリフレッシュ信号有りで簡易。
intelは8202とかいうDRAM制御ICもあったが高価杉。z80がパソコン利用で
主流になれたのはDRAMとの相性に良さだよね。って常識か。

534 ：ナイコンさん：2021/05/29(土) 14:21:57.79 .net

>>509
俺はなぜかMIPS君と呼ばれてるんだが
初めて覚えたアセンブラは8086だからキャリーフラグを知らないわけないぞ

MIPSでADD命令やSUB命令使ってオーバーフローが発生すると
トラップが発生するから使い物にならないとか言ってて
トラップが必要ない演算(C言語では普通トラップは発生させない)では
ADDUやSUBUを使うことを知らない無知だったのはMIPS君呼ばわりする人の方
彼はキャリーフラグがなくても32bit CPUで64bit演算ができるのを知らなかったしな

535 ：ナイコンさん：2021/05/29(土) 14:26:14.22 .net

CP/M86の8086のアセンブラASM86はCP/Mとかの8080コードをソーストランスレータ
とかで逐行8086変換してアセンブルする64kスモールモデルなcomファイル用途で簡易。
アレでミディアム-ラージモデル記述は難しかったろうね。MASMはセグメントディレクティブ
をそれなりにサポートしてはいたがintel純正のROM焼き目的なASM86のシンタクスの
サブセットだったっすね。com/exeファイル生成できればいいわけでという。

536 ：ナイコンさん：2021/05/29(土) 14:30:57.42 .net

まあ、8086は8bit CPUに比べれば断然アセンブラで書きやすいと思うよ
あくまで8bit CPUと比べてだけどね

16bitでは最初に出てきたつなぎのマイクロプロセッサなので8bitと16bitの中間的なのはしょうがないよね
だけど、16bitでは8086が普及してしまって
DOSの末期や16bit Windowsの末期は大変なことになってしまった

Windows 95があれだけ絶賛されたのは8086ベースのDOSや80286ベースのWin3.xがそれだけ酷かったから
だけど、支持されたのはビジネス向けではパソコンは
表計算ソフトとワープロ、会計ソフトが使えればそれでよかった時代だったから
動画編集はまだパソコンでは荷が重かったし、画像編集やDTPはMacの独壇場だったしね

537 ：ナイコンさん：2021/05/29(土) 14:35:46.11 .net

Z80は、レジスタの扱いの制限がなくて対称性が実現できていたら、もう少しコンパイラと親和性出たのかね？

538 ：ナイコンさん：2021/05/29(土) 14:51:44.35 .net

>>537
Z80伝説という本によるとザイログはZ80でUNIXのようなマルチタスクのOS作って
Z-Netとして販売してたらしいよ
でも売れなかったらしい
需要がなかったんだろうね

16bitCPUではマイクロソフトがいろいろな16bit CPUにUNIXを移植して
ZENIXとして販売してたし
Z8000ではUNIXが移植されてミニコンとして販売されてた模様
68000はApolloやSunのワークステーションに使われたのは有名な話

539 ：ナイコンさん：2021/05/29(土) 15:20:08.54 .net

>>536
ラージモデルでセグメント境界ごえアクセスを多用するだけでも少しばかり面倒なのに、EMSメモリとか、一部の用途だけとは言えハイメモリ領域を駆使してメインメモリを圧迫しにくいのを書いたりとか、面倒な使い方が続々と開発されてたよなあ

540 ：ナイコンさん：2021/05/29(土) 15:23:29.84 .net

>>537
コンパイラのはくコードとか見てみたら、レジスタ使用の対称性って、意外と必要ないんじゃないかと思った
X68000の純正cコンパイラとか、68000ならではの対称性の高さもレジスタの多さもぜんぜん活用されてなかったしなあ

541 ：ナイコンさん：2021/05/29(土) 15:55:45.64 .net

68000のおかげでエンジニアリングワークステーションが誕生したからね
ApolloなりSunとかのね
それまではその分野で大きなミニコンが使われてたわけで
それだけでも価値あったのでは？
68000が良すぎたのでZ8000はあまり相手にされずに消えていった

542 ：ナイコンさん：2021/05/29(土) 16:05:30.14 .net

Z8000ってトランジスタ数は減らしての高性能を狙ってて、
量産さえ進めばコスパ良くなりそうだったのにな

543 ：ナイコンさん：2021/05/29(土) 16:06:51.44 .net

8086が出た時代はあれでよかったけど
80286で68000のようにレジスタの32bit化をしてほしかったね
そうすればDOSの末期にあんな酷いことにならなかった
時代は32bitもどきの16bit CPUを必要としてた

544 ：ナイコンさん：2021/05/29(土) 16:18:19.19 .net

>>537
IXとIYの代わりにSP相対アドレッシングとHL相対アドレッシングとを追加すれば良かったんじゃないかな
追加レジスタ操作に1バイト増やすくらいなら、更に1バイトアドレッシングに使って2バイト増えてる方がマシだった

545 ：ナイコンさん：2021/05/29(土) 16:25:42.98 .net

アーキテクチャ

546 ：ナイコンさん：2021/05/29(土) 16:46:36.06 .net

>>529
> 「8080」なら他の3種類のCPU（MPU）とほぼ同性能だけど16ビットの「8086」では
> 性能が違い過ぎて、どのCPU(MPU)が優れているかの議論は無駄でしょ、って趣旨。
だからその趣旨なら
> プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
なんて要らんやろ
要ると言うなら理由を書けよ

> 尚、煽る気は微塵もない。「煽り」と言って自分の勘違いを正当化しないで貰いたい。
> 他人は見下すし、自分の間違いは「すまんすまん」では上から目線で何様なんだろうな。
もしかして相手は一人とか思ってる？

547 ：ナイコンさん：2021/05/29(土) 16:54:42.18 .net

いつもの事だが、大人気ない

548 ：ナイコンさん：2021/05/29(土) 17:11:32.99 .net

自分もスレタイになぜ8086が入ってるのかと違和感を感じていたほうだけど
>>2の過去スレ一覧から初代スレ見に行ったら
Z80 vs 6809 を唱ってる割には8086もそれなりに話題に登場してて
（ベストセラーとして外せないのは理解できる）
実情に合わせたスレタイ変更ということで納得した

549 ：ナイコンさん：2021/05/29(土) 17:46:41.70 .net

>>546
既に書いてるけど君とは感覚・意見が違うようだ。しつこいな、ワッチョイが必要かもな。

550 ：ナイコンさん：2021/05/29(土) 17:53:44.43 .net

>>546
この下の3行目が君のレスなら4行目が感想だ。
> プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
＞だとどう見ても8086はアセンブラでは開発しづらいクソCPUと言ってるように見える
そんなことは「一言」も書いてないのに「君が勝手に妄想して」そう解釈しただけだろ。

551 ：ナイコンさん：2021/05/29(土) 18:16:53.57 .net

このスレはIDがなくて混乱するな

俺はMIPS君と呼ばれてる人間だが
8086の酷評は68000に対してのものだからね
他の8bit CPUと比べれば8086は高機能
だからIBM PCに採用された
IBMはApple IIを潰したかっただけだからね
アセンブラレベルでもZ80と8086や8088とを比べると
断然8086、8088の方が書きやすいよ

IBMはApple II対抗の8bitパソコンが欲しかっただけなので
データバスが16bitの8086ではなくデータバスが8bitの8088を採用した

552 ：ナイコンさん：2021/05/29(土) 18:18:22.00 .net

>>544
IX/IYでメモリアクセスする命令は2バイト増えてるから「2バイト増えたHL相対」だな。
SP相対はCの自動変数と相性がいいが、8080上位互換のために命令のビットパターンが空いてないか。

553 ：ナイコンさん：2021/05/29(土) 19:41:02.71 .net

> DOSの末期にあんな酷いこと
どんな妄想してるか知らんが圧倒的なソフト、ゲーム資産、アセンブラで書かれた高速なアプリ群。
DOSユーザーは天国でしかなかったぞ。

554 ：ナイコンさん：2021/05/29(土) 19:54:42.40 .net

1970年代に開発ではまだパソコンなんてジャンルはなく、
マイコン、組込的な用途を想定しての開発だろう。
8bitCPUでCを考慮した作りとか想定外だろうな。

555 ：ナイコンさん：2021/05/29(土) 19:57:51.41 .net

DOS窓でメモリ不足で動かせず、ランチャーとして使えない、DOSとWinを別物として使うしか無い状況の事かね？
日本語環境だとFEPの分でコンベンショナルメモリ足りなく、CONFIG.SYS弄りまくりで普通の人が使えるものでは無くなってたってな
Win入ってるのにフロッピー立ち上げとかな悲惨な人々を産んでたな

556 ：ナイコンさん：2021/05/29(土) 20:05:59.96 .net

それはDOS末期ではなくWindows初期の話ですな。

557 ：ナイコンさん：2021/05/29(土) 20:13:56.43 .net

IRQが足りねーって悩みはいつの間にか解消してたな

558 ：ナイコンさん：2021/05/29(土) 20:21:39.28 .net

>>551
貴方を「MIPS君」と呼んでる方とは、どのようなイザコザがあったかは知りませんが
少なくても、このレスに関しては納得すると言うか、ほぼ同じ感想です。

>>553
DOSエクステンダーとかもありましたけど、どうような使い勝手だったのでしょうか。

尚、MSが商業的に上手いのは「Win 95」で16ビットも使える32ビットOSを用意し移行させたこと。
また同梱されたネット用アプリの存在が後押ししたこと。ただ後に独禁法で問題になった記憶ありと。

559 ：ナイコンさん：2021/05/29(土) 20:21:39.30 .net

ISAバスとか旧型の割り込みコントローラとかがIRQ不足の原因で、
拡張割り込みコントローラとPCIバスを活用できたら割り込み不足は起きない

拡張割り込みコントローラをネイティブモードで使えるのはNT系以後で9xでは互換動作しか使えなかったから、9xの頃までは割り込み数が常に足りなかった

多くの人にとってはXP以後またはWin2k移行によって割り込み不足から解放された

560 ：ナイコンさん：2021/05/29(土) 20:31:58.82 .net

>>549-550
だから違うと言うならどういう意図で
> プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
を書いたんだよ？って聞いてるんだが…
まあ答えられないからグダグダ言ってるんだろうけどw

561 ：ナイコンさん：2021/05/29(土) 20:37:37.74 .net

>>556
Windows 3.xの頃はDOS上でWindowsが動いてたんだから同じだぞ
それにまだゲームソフトの大半はDOS上で動いてて
CONFIG.SYSの設定をうまくやらないと起動しないゲームがたくさんあった

562 ：ナイコンさん：2021/05/29(土) 20:40:00.42 .net

ひとつの割込みを全部のイベントで共有しているPICでも問題がないというのに8086ときたら

563 ：ナイコンさん：2021/05/29(土) 20:47:26.73 .net

>>561
win95の頃でも、じつはブートローダーとしてDOSを使ってたから、DOS自体は動いてたけどな、
主要なコンポーネントがDOSから呼び出さないでwin95から呼び出すようになったから、DOS用のデバイスドライバを使わなくてよい分だけ安定するようにはなった

564 ：ナイコンさん：2021/05/29(土) 21:03:40.01 .net

8080や6502、6809でDRAMリフレッシュは実際
どうしてたのだろう。
8086/88でよく使われてるDMAなのだろうか。
6502でDMAってそもそもできるんだっけ。

565 ：ナイコンさん：2021/05/29(土) 21:19:39.60 .net

MIPS君は自分は32bitCPUなのに8bitCPUスレばかりを荒らしにくる人です。そして32bit演算できない8bitCPUを馬鹿にするのです。
キャリーフラグあるからadd,adc,adc,adcで簡単にできるが、MIPSは64bit演算するなら桁溢れは例外投げるからむしろ面倒と指摘すると、
adcの意味が通じなかったらしく、キャリーフラグがいかに害悪かを語りだしましたとさ。

しかし、自称RISCのARMやAVRはキャリーフラグがあっても高速、ストールしないと、あっさり論破され逃亡。

566 ：ナイコンさん：2021/05/29(土) 21:26:35.19 .net

>>564
Apple][の回路図とか
https://archive.org/details/applerefjan78/page/n149/mode/

567 ：ナイコンさん：2021/05/29(土) 21:34:52.94 .net

>>562
全部のイベントで共有すると、割り込みを使うアプリやドライバの調停が面倒になって製作を分業しにくかったのでは?

568 ：ナイコンさん：2021/05/29(土) 21:41:04.36 .net

>>565
また無知さらしてるよ
64bit演算で例外なんて投げないよ
$4:$5＋$6:$7＝$8:$9の64bit加算は
addu $9, $5, $7
sltu $10, $9, $5
addu $8, $4, $6
addu $8, $8, $10
でできる

569 ：ナイコンさん：2021/05/29(土) 21:48:07.85 .net

>>568
ハナから知ってる。なぜ知らないと思ったのかが謎。
だからそんな面倒のことしなくてもキャリーあれadd、adcで済むよねって話をしてるのに
MIPSだってできるとその面倒な演算を自慢されてもね。最初から面倒だと指摘してるだろうに。
しかもPSのゲームで桁外れでフリーズするゲームも見受けられる。

570 ：ナイコンさん：2021/05/29(土) 21:53:27.23 .net

>>569
知ってるならなんでこんなこと書いたんだろうかｗ

＞キャリーフラグあるからadd,adc,adc,adcで簡単にできるが、
＞MIPSは64bit演算するなら桁溢れは例外投げるからむしろ面倒と指摘すると

571 ：ナイコンさん：2021/05/29(土) 21:55:18.31 .net

例外投げるから例外投げないように
そういう馬鹿な書き方してることに気づいてないのか・・・

572 ：ナイコンさん：2021/05/29(土) 21:55:59.70 .net

ちなみにMIPSのC言語では加算は例外の発生しないADDUやSUBUが使われる
だからC言語で開発されたソフトで例外が発生するADDやSUBが使われることは
通常ないと思われる

573 ：ナイコンさん：2021/05/29(土) 21:57:45.15 .net

>>571
何度も言うが
ADDUやSUBUは例外は発生しない
オーバーフローで例外が発生するのはADDやSUB
ADDやSUBはC言語では通常使われない

574 ：ナイコンさん：2021/05/29(土) 22:00:31.32 .net

>>564
レスの内容からZ80は知ってることを前提として、6809はバスの状態を表すBA、BS
と言う端子があるから、FM-7 ではこの端子から出てる信号を利用して生成してるような。
秀和から出たF-BASICマニュアルI（基礎編）のP261に回路図が掲載されてるので
東京以外に住んでるなら国会図書館のコピーサービスを使うと良いのでは。

575 ：ナイコンさん：2021/05/29(土) 22:01:17.52 .net

命令削減することがRISCの思想。キャリーがあるとADD、ADCと命令増えてしまうと批判していた。
つまり、例外発生するから発生しないバージョンの命令を増やしてしまったMIPSは
RISCを名乗るなということです。

576 ：ナイコンさん：2021/05/29(土) 22:03:52.09 .net

CやUNIXに使う前提なら元から桁溢れで例外発生する必要はないよな。
キャリー捨てたことであらゆるところがおかしくなってる。

577 ：ナイコンさん：2021/05/29(土) 22:04:16.59 .net

>>575
都合が悪くなると話し変えるね、君は
そして自分の都合のいいように話しを変えて他で吹聴しまくる

578 ：ナイコンさん：2021/05/29(土) 22:06:42.24 .net

>>576
RISC-Vもキャリーフラグないけど、RISC-Vにもいちゃもんつけてるの？
RISC-Vの基本命令はMIPSに非常に似てるよね

579 ：ナイコンさん：2021/05/29(土) 22:07:35.26 .net

addu $9, $5, $7
sltu $10, $9, $5
addu $8, $4, $6
addu $8, $8, $10

これ見て面倒なことしてるなと思わない奴がこのスレにいるの？
このスレのチップじゃどれもadd、adc並べるだけだよ？

580 ：ナイコンさん：2021/05/29(土) 22:07:59.98 .net

RISC-Vは糞。このスレでは結論出てる。

581 ：ナイコンさん：2021/05/29(土) 22:11:05.92 .net

そういい張ってればいいのでは？
数年後が楽しみだね

582 ：ナイコンさん：2021/05/29(土) 22:16:47.05 .net

いやもう10年経ったんだ…

583 ：ナイコンさん：2021/05/29(土) 23:09:33.74 .net

>>555
まあ酷かったと言えば酷かった
OSでランチャーまでありながら、config.sysをアプリごとに持って再起動したりしてね
HSBとか駆使すれば問題なかったけど、環境構築に相当時間使ったわな

584 ：ナイコンさん：2021/05/29(土) 23:15:21.04 .net

MIPSとかWindowsとか他でやってくれ。ほんと32bitスレは他にもいろいろあるだろ。
どんだけ8bitCPUにマウンティングしたいんだか。

585 ：ナイコンさん：2021/05/30(日) 00:02:44.37 .net

野球場でのサッカーに夢中らしい
他の人の視線は気にせずに
言ってることは頭いいらしく自分に酔いしれる
やってることは馬鹿だけども

586 ：ナイコンさん：2021/05/30(日) 00:15:45.11 .net

>>585
一言言わなきゃ気が済まないってのは
スレ違いの話を延々する人間と同じ思考回路だよ、要するに同じ穴の狢
みんな後少しくらいなら、自分も一言って続けてるだけなんだから

587 ：ナイコンさん：2021/05/30(日) 00:17:33.32 .net

話戻すけど、アセンブラやってたらCのポインタを理解できると勘違いしてる奴がたまにいるが、
それはインデックスレジスタ持ってるCPUだけだからな。よって6502は当然除外される。

588 ：ナイコンさん：2021/05/30(日) 00:28:07.41 .net

関節アドレッシングと何が違うんだ？

589 ：ナイコンさん：2021/05/30(日) 00:40:47.40 .net

アドレス演算ができる。

590 ：ナイコンさん：2021/05/30(日) 00:43:11.09 .net

大きな「糸」と言う詩でも添えたいけど才能がないのでリンクだけ
「c言語でファミコンプログラミングしているTKOZです」（因みに自分ではありません）
ttps://dixq.net/forum/viewtopic.php?t=3943

591 ：ナイコンさん：2021/05/30(日) 00:52:12.84 .net

ポインタが理解できるかどうかってのは概念では？

592 ：ナイコンさん：2021/05/30(日) 00:53:04.68 .net

8bitだけど「インデックスレジスタ」が2本あると書いてます。
ttp://hp.vector.co.jp/authors/VA042397/nes/6502.html

593 ：ナイコンさん：2021/05/30(日) 01:01:07.66 .net

Cのポインタとは程遠いですな。
cc65のポインタ実装はどうなってるか見てみるといいですな。

594 ：ナイコンさん：2021/05/30(日) 01:13:26.95 .net

その8ビットサイズのインデックスレジスタって、ゼロページというローカルメモリのなかを指し示すためのレジスタだよな
それ以外のメモリエリアには使えない。

595 ：ナイコンさん：2021/05/30(日) 01:29:01.53 .net

>>593
貴方は>>587氏と同一人物ですか？ それであれば先ず
6502にインデックスレジスタはないCPUと言う前提が違ってます。

アセンブラを理解してる前提でCのポインタを理解できるか否かは本人次第で、6502とは関係ない。
「アセンブラを理解してる」ことが「Cのポインタを理解できる」十分条件にはならないでしょう。

また、下を見れば
ttps://cc65.github.io/doc/cc65.html#s4
strcmp()、 strcpy()、 strlen()等があり、ポインタなしに、どのように実現してるのでしょうか？

>>594
ゼロページではないのではと。

596 ：ナイコンさん：2021/05/30(日) 01:31:59.37 .net

>>595
sbc、decで減算できるということは理解できましたか？

597 ：ナイコンさん：2021/05/30(日) 01:36:05.88 .net

アブソリュート・インデックストX：絶対番地にXレジスタの値を加算した番地を指定する。
ttps://ja.wikipedia.org/wiki/MOS_6502

598 ：ナイコンさん：2021/05/30(日) 01:43:58.89 .net

>>595
知りたいならコンパイラの実装見てみればいいのではと言ってるのに
なぜおれに質問してくるのだ。意味不明な奴だ。

599 ：ナイコンさん：2021/05/30(日) 01:43:59.99 .net

>>596
何の話か後ほど詳しく聞きます。現在の話は>>587氏のレスの
「CPU（MPU）6502はインデックスレジスタがない」と言うことが事実か否かです。

これにケリをつけてからにしましょう。

600 ：ナイコンさん：2021/05/30(日) 01:45:33.09 .net

コミュ障にもほどがあるぞ。頓珍漢なツッコミばっかしてきやがって。
何が6809の経験あるだ。アセンブラど素人じゃねーか。

601 ：ナイコンさん：2021/05/30(日) 02:05:38.63 .net

Indirect Index addressing modeが分からないんだと言うのが良く分かる例になってるな

602 ：ナイコンさん：2021/05/30(日) 06:58:27.06 .net

6502にインデックスレジスタはあるし、ポインタの理解にインデックスレジスタが必須なわけでもない
要するに>>587は単なるレス乞食

603 ：ナイコンさん：2021/05/30(日) 07:00:08.30 .net

6502にインデックスレジスタはあるし、 ポインタの理解にインデックスレジスタが必須なわけでもない
要するに>>587は単なるレス乞食

604 ：ナイコンさん：2021/05/30(日) 07:35:24.20 .net

DOS末期でコンベンショナルメモリ不足とかまるで見てきたような話してるが、いつものホラ吹きが妄想独演会か？
むしろ末期はメモリマネージャの進化でメモリ空け易かった、最大メモリの実現もDOS5.x以降の話だしな
ドライバやアプリ側もハイメモリやEMSへの退避やオーバーレイが普及してコンベンショナル領域のフットプリントは減少

あとはこういった設定の最適化が難解で無理だったとかまた見てきたような嘘を並べるんだろうけど
バカでも使えるメモリマネージャがconfig自動で作成してくれたので、それこそバカでも使えたのがDOS末期〜Windows.x/9x世代

出たばかりの頃のDOS2.11に自分でFEP組み込むとかの方がバカには無理だったよな
情報も無かったし、助けを乞おうにもネットどころかパソ通すら無理だろそんな連中

605 ：ナイコンさん：2021/05/30(日) 07:46:42.17 .net

一般的な処理系のインデックスレジスタと6502のインデックスレジスタを同列で語るなよ
前者はアドレスを指すもの。6502はオフセット的な用途。後者は明らかにCのポインターとは異なる。

606 ：ナイコンさん：2021/05/30(日) 08:02:52.80 .net

>>605
int *p = ...;
int i = ...;
int x = *(p + i);
みたいな書き方知らんのか？

607 ：ナイコンさん：2021/05/30(日) 08:32:17.09 .net

>>604
DOS末期はWindows 3.x時代も含まれるだろ
ゲームはまだまだDOSの時代だぞ
メモリに付属してたメモリマネージャでコンベンショナルメモリ開けないと
起動できないゲームたくさんあったぞ

608 ：ナイコンさん：2021/05/30(日) 08:34:59.03 .net

だいたいCのポインタごときそんな難しいかよ
6502でもなんでも、アセンブラで考える頭あったら、あんなの当たり前だろう

609 ：ナイコンさん：2021/05/30(日) 08:42:10.76 .net

>>604
自分も記憶があやふやなのでは…
Win9xと書いてるが少なくとも98ではもうconfigとか気にしてた奴なんかいなかっただろ

610 ：ナイコンさん：2021/05/30(日) 08:43:39.13 .net

＞使えたのがDOS末期〜Windows.x/9x世代

DOS/Windows 3.x時代とWindows 9x時代を一緒にしてるのが当時を知らない人らしいよな
明らかに時代が変わってるのに
Windows 9xでゲームもWindowsに移行して直接DOSをいじる機会が激減したんだよ
CPUもPenitumに移行してメインのバスがPCIバスが主流になってプラグアンドプレイで増設が楽になった
Windows 3.xからWindows 95への移行はすごいスピードで進んだ
当時はそれだけWindows 95が画期的だったんだよ

611 ：ナイコンさん：2021/05/30(日) 08:48:09.49 .net

Windows 98の時代になると今度はシステムリソースの問題が顕在化してきたけどな
あれもセグメントによる弊害の一つ
たしかシステムリソースの領域が128KBしかなかったんだよな

612 ：ナイコンさん：2021/05/30(日) 08:56:44.72 .net

>>608
ポインタはmallocとかの動的エリア確保機能とセットでOSの癖が出易い部分。
turbocには64KB超の配列を自動利用できるhugeモデルがあったがASMだと
面倒だろ。macだと動的メモリはポインタを指すハンドルをロックして関節
アクセスしないと即爆弾が破裂したし。web初期の時代だとDDoS攻撃で
バッファポインタの脆弱性が散々叩かれたし。安全性やセキュリティでCが弱みを
曝け出すのがポインタだったね。

613 ：ナイコンさん：2021/05/30(日) 09:18:04.57 .net

>>610
DOS時代に勇明を馳せたゲーム会社にはWindows95時代の初期にビジネス
畳んで撤退ばいばいしたところ多いよね。Sierraとかmicroposeとかorigin、
sirtechとか、WindowsになってDOSゲームが仮想ビデオなMacもどきの
ゲームスタイルを強制されるような状況がDirectXs初期の仕様迷走で印象付け。
面白くもないMacゲームみたいなウィンドウ内ちょこちょこげーむなんか
作っていられるかよみたいに考えたデベロッパーが数多いたみたいね。
でWindows95を境に選手大幅入れ替えが起きていたよなあ。しばし新作停滞。

614 ：ナイコンさん：2021/05/30(日) 09:52:44.78 .net

>>612
難しいと面倒なのは違うぞ

615 ：ナイコンさん：2021/05/30(日) 09:57:16.08 .net

>>610
> Windows 3.xからWindows 95への移行はすごいスピードで進んだ
> 当時はそれだけWindows 95が画期的だったんだよ
移行と言うより新規勢が大量流入した
パソコン持ってない奴まで95を買う勢いだったしなw
まあTCP/IP標準装備のインパクトも大きかったけど

616 ：ナイコンさん：2021/05/30(日) 10:42:22.29 .net

>>610
「当時を知らない人」については他の可能性も。尚、コンベンショナルメモリについて
業務用アプリ等で実際足りなくなって来たのでDOSエクステンダーが開発されたかなと。
コンベンショナルメモリ不足に対しCコンパイラではオーバレイ構造が可能だったけど
リニアにアクセスできる物理メモリ量はあるのでセグメントの悪影響が残った感じだった。

尚、大筋では同意だけど「Win9X」については次の>>611氏が指摘するように16ビット時代の
システムリソース管理を流用してたので物理的なメモリ量はあるのに頻繁にリソース不足状態が
発生しOSの再起動が必要だった。即ち16ビットコードを使える利便性と弊害は背中合わせだった。

617 ：ナイコンさん：2021/05/30(日) 10:49:50.49 .net

>>614
同一の問題でもスキルの乏しい若年では解決は難しい。
しかし経験豊かな先達には面倒だが解法明らかで解決は可能。

618 ：ナイコンさん：2021/05/30(日) 11:21:22.84 .net

>>617
言ってることが当たり前過ぎて何を言いたいのかさっぱりわからんw

619 ：ナイコンさん：2021/05/30(日) 11:36:17.07 .net

6502は命令デコード中に次の命令コード読んでいるだけでも速い上に
Z80がADC A,(d16 + C) 相当の命令を8clockで実行できるようなものだから
低クロックで貧相なレジスタセットでもどうにかなっている

620 ：ナイコンさん：2021/05/30(日) 13:00:39.79 .net

>>612
＞macだと動的メモリはポインタを指すハンドルをロックして関節
＞アクセスしないと即爆弾が破裂したし。
上のレスにも「関節」とあるので「間接アクセス」の誤変換と言うことで理解するけど
具体的なコードを提示して下さい。自分としてはポインタとは動的に確保されたメモリブロックの
先頭アドレスと理解していて、ハンドルと言えば、ポインタで記述されてるとは言え FILE *file;
のように file の中身は操作せず入出力データをポインタで示すメモリブロックに（から）転送する
時に使う識別子と考えています。またmacとは「APPLE�U」のことですか、それとも最近のMacのことですか？
どちらにしても「C言語」の具体的なコードをお願いします。

621 ：ナイコンさん：2021/05/30(日) 13:07:52.00 .net

追伸
ポインタとは必ずしも動的に確保されたメモリブロックの先頭アドレスではないけど
今回、動的メモリ限定で考えています

622 ：ナイコンさん：2021/05/30(日) 13:43:05.00 .net

わかってたら収束しそうなとこに違う話を持ち込んだりしないから
残念なひとなんだとおもう

623 ：ナイコンさん：2021/05/30(日) 14:00:08.40 .net

「自動的に開放」とかいう宣伝文句で行儀の悪いプログラムを書かせる風潮にも困ったもんだ
そんなにメモリ管理隠したいか

624 ：ナイコンさん：2021/05/30(日) 14:08:34.15 .net

今のアプリケーションの規模でメモリ管理を人手を介してなんてやってられんでしょ
メモリ確保とか宣言とか機械の都合に対応するための妥協の産物なんだから
人がやらなくていいならそれに越したことはない

625 ：ナイコンさん：2021/05/30(日) 14:44:18.86 .net

>>620
メモリーハンドルも知らないみたいだしポインタを動的メモリー限定で考えるとか頓珍漢なこと言ってるしね
本人の認識よりだいぶレベル低いと思うw

626 ：ナイコンさん：2021/05/30(日) 15:02:10.75 .net

>>606
ポインタのポインタとか、できないじゃん6502

ポインタが指し示すメモリにポインタ値が入ってるものとして使うやつ

それか、関数のアドレスをポインタとして取得して、それを使って関数呼び出すやつとか

627 ：ナイコンさん：2021/05/30(日) 15:06:23.34 .net

>>604
うーん、DOS5DOS6の頃でもコンベンショナルメモリ不足で悩んでる人の話は、対処法とかの話は雑誌を賑わしてた気がするが
むしろDOS4までの頃より記事が多かった気がする

俺には対岸の火事で、自動で設定するだけで足りたけどさ。
あ、俺が使ってたのはエプソン版のDOS6な、発売元によってバンドルソフトとか細かく違ってたんだよな。じつはメモリマネージャも違ってたような気がする?

628 ：ナイコンさん：2021/05/30(日) 15:17:46.06 .net

>>626
> ポインタが指し示すメモリにポインタ値が入ってるものとして使うやつ
ポインタが指し示すメモリの内容を読めるならそれをポインタだと思ってその先をもう一回読み出すだけやん

> それか、関数のアドレスをポインタとして取得して、それを使って関数呼び出すやつとか
戻りアドレスプッシュして間接ジャンブするだけ

知能ないのか？w

629 ：ナイコンさん：2021/05/30(日) 16:43:52.09 .net

>>625
「間接」と言うべき所を「関節」と言った理由は関節にガタがきてるからですか？

「メモリーハンドル」でググったら古臭いMAC特有のローカルなメモリ管理方法と判りました。
Macのメモリが少なく、MMUなんて高級なハードウエアを備えていなかったことが理由とある。
8ビットでもMMUがあるCPU（MPU）があったと言うのに化石レベルのMACの話でしたか。

流石、古の知識を大事にしてる「レジェンド」です。

630 ：ナイコンさん：2021/05/30(日) 16:56:51.92 .net

>>629
> 「間接」と言うべき所を「関節」と言った理由は関節にガタがきてるからですか？
あれ？
まだそんなところに拘っわってるの？
理解したとか言ってなかったっけ？

> 上のレスにも「関節」とあるので「間接アクセス」の誤変換と言うことで理解するけど

まあ単なるタイポだと思うけどそう言うのは>>588,612に聞いてくれ
お前の相手は一人じゃないからw

> 流石、古の知識を大事にしてる「レジェンド」です。
取り敢えずここの板がどんな板なのかぐらいは理解して書こうな
マジで痛々しいぞ

631 ：ナイコンさん：2021/05/30(日) 17:00:45.76 .net

こんなもんがアドレスの真ん中に居座っていたら破綻するかもって不安な時は文句言われてもGlobalAlloc（）

632 ：ナイコンさん：2021/05/30(日) 18:26:16.59 .net

>>628
いや、ゼロページを指すレジスタしかないなら無理だろと

メインメモリのアドレス指定できるアドレシングレジスタあったの、6502

633 ：ナイコンさん：2021/05/30(日) 18:53:47.98 .net

クソスレ
クソレス
乙

634 ：ナイコンさん：2021/05/30(日) 19:49:15.05 .net

>>632
>>601にも書いてあるIndirect Index addressing modeについて調べてこい

635 ：ナイコンさん：2021/05/30(日) 19:54:12.70 .net

8bit縛り故にの苦肉の策のアドレッシング。Index Indirect、Indirect Index。
むしろこんな恥ずかしい機能でマウンティング取るなよ。恥ずかしい。
こんな糞機能使ってられないからウォズもSweet16作ったのだろう。

636 ：ナイコンさん：2021/05/30(日) 20:17:00.96 .net

>>625
ポインターは静的に使うことは勝手だがそう使えるから動的で前提で考えるなとかちよっと何言ってるか分からない。

静的ならコードにアドレス埋め込むのでチープなCPUでも実装できて当たり前なのだから。
動的なら6502は16bitレジスタ持ってるCPUより面倒な実装が必要だということ。

637 ：ナイコンさん：2021/05/30(日) 20:51:28.00 .net

>>635
> 8bit縛り故にの苦肉の策のアドレッシング。Index Indirect、Indirect Index。
意味わからん、68020にもあるぞ

> むしろこんな恥ずかしい機能でマウンティング取るなよ。恥ずかしい。
マウントと思うお前が恥ずかしいわw

>>636
staticに確保したバッファーをstrlen( )に渡すとかあるだろ
渡された側は動的確保か静的確保なんて関係ないし

638 ：ナイコンさん：2021/05/30(日) 21:46:08.40 .net

> staticに確保したバッファーをstrlen( )に渡すとかあるだろ
バッファの先頭アドレスはコードに埋め込まれると思うが誰かcc65で試してくれ。

639 ：ナイコンさん：2021/05/30(日) 22:01:39.75 .net

C言語のポインタなんて、CPUに拠らずアセンブラの経験がありゃ躓いたりしないだろうに。
「動的に値が変わる変数が示すものがメモリの番地」ってだけなんだし。

CPUがどう表現するかなんて些末なことでポインタが理解できないっていう奴が居たらそいつの知能を疑うべきだわ。

640 ：ナイコンさん：2021/05/30(日) 22:02:21.36 .net

>>636
ポインターが静的に確保されたメモリでも動的に確保されたメモリでも
同様に扱える事は当然として動的限定の話の発端は>>612氏の下の指摘。
1）ポインタはmallocとかの動的エリア確保機能とセットでOSの癖が出易い
2）macだと動的メモリはポインタを指すハンドルをロックして間接アクセスしないと爆発

それでMACは動的エリア確保する場合に何が違うかと言うと、ポインタで一重管理する時と
ポインタのポインタで二重管理する時があると言う話が発端かなと。

>>637
一々言うことに棘があるが実生活や仕事で上手く行ってないのか。老い先短いから仲良くしようぜ。

641 ：ナイコンさん：2021/05/30(日) 22:10:01.54 .net

>「動的に値が変わる変数が示すものがメモリの番地」ってだけなんだし。
インデックスレジスタとCのポインタの違いを全然理解してなくて笑える。

642 ：ナイコンさん：2021/05/30(日) 22:14:29.21 .net

日本でアセンブラ経験者といえばZ80ばかりだっただから、Cのポインタで躓く人は少ないよ。
じゃあなぜアセンブラ未経験者がポインタで躓くのか。BASICやPASCALでは躓かないのに。

643 ：ナイコンさん：2021/05/30(日) 22:15:19.03 .net

>>638
まぁ>>637はトゲトゲしいから誤解を発生させているが、staticに確保したバッファーを
strlen( )に渡す時は先頭アドレスはコードに埋め込まれると思う、staticだから。
趣旨としては、ポインタに入れるアドレスは動的確保か静的確保には関係ないと言う事だろ。

644 ：ナイコンさん：2021/05/30(日) 23:04:08.50 .net

>>640
> 一々言うことに棘があるが実生活や仕事で上手く行ってないのか。老い先短いから仲良くしようぜ。
いきなりマウントとか言い出す>>635に言ってやれよw

645 ：ナイコンさん：2021/05/30(日) 23:07:44.83 .net

>>642
> 日本でアセンブラ経験者といえばZ80ばかりだった
どこの日本よw
8bit時代はZ80一強じゃなかったぞ

> じゃあなぜアセンブラ未経験者がポインタで躓くのか。BASICやPASCALでは躓かないのに。
BASICには標準でポインタなんて無いし、Pascalは陽にアドレスを扱わないから

646 ：ナイコンさん：2021/05/30(日) 23:28:10.97 .net

アドレス扱うからCのポインタで挫折するという謎理論登場。

メモリは場所を特定するために0から順にアドレスが振られてます。
つまりこれが理解できずに挫折するのか。

647 ：ナイコンさん：2021/05/30(日) 23:40:02.54 .net

>>645
16進コードはスラスラ読めるのに「C言語」は知らないと言う人に出会ったことはあるけど。

それでポインタがアドレスを入れる変数ならポインタのポインタは、ポインタのアドレスを入れる変数と言う事。
以下、どこまでループできるのかはコンパイラの仕様なのかと。「C言語」自体は数週間で覚えた口だけど
一箇所だけ躓いた。構造体に同じ構造体を入れる時。結局リスト等で、構造体の中には構造体のポインタがある
と言うことでスッキリ解決したが、これがなければ1週間で覚えた。尚、アセンブラは6809しか知らんけど。

>>646
それだけではないと思う。宣言が「int *a；」で かつ 「a = &b；」なら *a で b の値を表してるから。
結局、「*」の使い方が二通りあることも起因してると考えてる。

648 ：ナイコンさん：2021/05/30(日) 23:47:50.16 .net

そう。ポインタの混乱の原因はCのシンタックスが糞だから。
ただただ読みにくいことが原因。

649 ：ナイコンさん：2021/05/30(日) 23:51:15.28 .net

>>646
ああ、説明不足だったな
Pascalではポインタ変数への操作が限定されてるって書いた方がわかりやすいかな

650 ：ナイコンさん：2021/05/30(日) 23:59:58.03 .net

offsetがsizeofなとこ以外は
アセンブラやってたらポインタで躓くことあるかな
メモリ管理(ライブラリやOS)の話はターゲットによるからどうでもいい

651 ：ナイコンさん：2021/05/31(月) 00:00:51.35 .net

ポインタのポインタあたりまではまだいいが、関数のポインタとか型キャストまで入ってくるとさすがに混乱した

数値をポインタ型に型キャストとか、ややこしい

数値を「関数のポインタ」型に型キャストして関数呼び出しされたりすると、なにそれって

652 ：ナイコンさん：2021/05/31(月) 00:01:45.00 .net

関数ポインタの宣言もそう。シンタックスが糞すぎる。

653 ：ナイコンさん：2021/05/31(月) 00:06:16.10 .net

論点の方角が明後日すぎてついていけない
各論客の結論はなんなんだろう

654 ：ナイコンさん：2021/05/31(月) 00:06:27.42 .net

>>636
アドレッシングで対応してるんだから、アドレッシングに乏しいCPUよりも面倒な処理をしなくても済む

655 ：ナイコンさん：2021/05/31(月) 00:07:51.50 .net

6502は糞。おれは一貫してる。

656 ：ナイコンさん：2021/05/31(月) 00:12:02.81 .net

知識の無さが一貫してるな

657 ：ナイコンさん：2021/05/31(月) 00:16:04.27 .net

>>651
なるほど。
アセンブラできてもCのポインタは苦手って人は
実際には「型」が苦手なんだな。

658 ：ナイコンさん：2021/05/31(月) 00:18:14.95 .net

>>656
むしろ6502叩きするたびに68000の話をしだすおまえの知性のほうが問題。

659 ：ナイコンさん：2021/05/31(月) 00:29:21.46 .net

そのとおり。インデックスレジスタとCのポインタの最大の違いは、ポインタは型情報を持っている。
16bit整数のポインタならp++;すればアドレスはちゃんと+2される。
アセンブラ書くときは脳内で型を管理してたけどCは言語機能で受け持ってくれる。

660 ：ナイコンさん：2021/05/31(月) 00:39:06.70 .net

Z80のソケットにそのままさせる6502があったら2倍の性能
載せたくなるようなZ80マシンが無かったのが幸い

661 ：ナイコンさん：2021/05/31(月) 00:42:53.90 .net

>>658
明らかに何人も書き込んでいるのに、自分以外は一人だけとか危ない思考すぎる

662 ：ナイコンさん：2021/05/31(月) 01:06:14.09 .net

>>658
Indirect Index Addressing Modeごときでマウントとか言い出す性格の方が問題だろ
まあ知らなかったから恥ずかしさのあまりって奴なんだろうけどw

663 ：ナイコンさん：2021/05/31(月) 01:07:59.25 .net

>>655
知ったか無能には糞に見える
確かに一貫してるわ、6502に限らず

664 ：ナイコンさん：2021/05/31(月) 01:17:26.36 .net

>>660
そりゃ6502はZ80よりは早いんだろうけど、6809とか6502が2MHzくらいで
Z80はなぜ4MHzだったのかは確認することをおすすめします。

665 ：ナイコンさん：2021/05/31(月) 02:18:11.41 .net

妄想ばかり語る6502信者はどうせマカーだろう。

666 ：ナイコンさん：2021/05/31(月) 03:55:15.42 .net

歴史が証明してる。CP/Mのような6502のソフト資産群は何もない。

667 ：ナイコンさん：2021/05/31(月) 06:17:44.05 .net

>>665
妄想ってなんのこと？
具体的に書いてみ

668 ：ナイコンさん：2021/05/31(月) 06:28:09.99 .net

AppleIIユーザも開発時にMSのZ80ボードさしてCP/M上で開発してる人も多かった。

669 ：ナイコンさん：2021/05/31(月) 06:32:48.66 .net

そういえばファミコンの大戦略はほんと酷かった。
8bitPC版よりあれほど劣化してあの遅さは6502のせいだと思う。

670 ：ナイコンさん：2021/05/31(月) 06:41:07.36 .net

>>669
扱うデータが256バイト超えたとたんに激遅になるCPUだからしかたないね。

671 ：ナイコンさん：2021/05/31(月) 06:41:24.31 .net

Cのポインタアクセス構文を一命令で実行しないといけない縛りでもあるのかwww

そんなのCPU毎に使える命令並べて再現するだけだよね
CPU毎に効率違うよね、で済む話w

672 ：ナイコンさん：2021/05/31(月) 06:44:39.80 .net

ゼロページ番長。高速なのはワークエリアが256バイトに収まるときだけ。アクションゲームは得意だがSLGは大の苦手。
というかそのアクションゲームもファミコンのようなハードウェア支援ありきだけどな。
普通の8bitPCみたいに高解像度のVRAMに自分で描画しろとなると途端に破綻する。

673 ：ナイコンさん：2021/05/31(月) 06:56:04.32 .net

>>671
そのとおり。スレタイのCPUでCとの相性が一番悪いのは6502というだけ。
なぜなら元々Cが16bit機向けに開発された言語だからね。16bitレジスタないとか全く想定していない。
8086のセグメントもCのポインタとの相性は最悪だけどね。

674 ：ナイコンさん：2021/05/31(月) 07:27:48.00 .net

>>666
VisiCalcって知ってるか？w

675 ：ナイコンさん：2021/05/31(月) 08:17:11.33 .net

>>674
使ったことないのかw

676 ：ナイコンさん：2021/05/31(月) 08:34:22.24 .net

しょぼいマイコンに移植したことは画期的といえば画期的だったが
当時のしょぼい表計算ソフトに何を期待しているんだ。

納税申告に必要だと売りまくったが四則演算すらまもとにできんアメリカ人が多いのに
あのソフトが使いこなせたかは謎。

677 ：ナイコンさん：2021/05/31(月) 10:06:54.16 .net

OPコードが１バイトのLD A,(HL+d8)があったとしても15clockもかかるZ80
ポインタの周辺アドレスアクセスが苦手なZ80がCに一番不向き

678 ：ナイコンさん：2021/05/31(月) 10:41:12.54 .net

>>676
最下層は知らんけどアメリカは自分で申告しないと駄目だからそれなりの層が飛びついたんだよ

679 ：ナイコンさん：2021/05/31(月) 10:42:57.86 .net

>>677
まあ8086や6809ならともかくZ80と6502だとどんぐり背比べにしかなってないだろw

680 ：ナイコンさん：2021/05/31(月) 10:56:48.47 .net

mov ax,(bp+d8)
8086は17clockかな。

681 ：ナイコンさん：2021/05/31(月) 10:58:52.53 .net

6809も向いてるようで動作速度として結局は余り向いてない

682 ：ナイコンさん：2021/05/31(月) 11:27:26.19 .net

>>681
それは8bit CPUとしての話？
それとも今のCPUと比べての話なの？

683 ：ナイコンさん：2021/05/31(月) 11:33:32.29 .net

>>676
移植する前の元のアプリは何だったのかと？

>>677
＞ポインタの周辺アドレスアクセスが苦手なZ80がCに一番不向き
周辺機器を操作する時にポインタを使うと言う話かな。確かに
AppleIIは早くからFDDが装備されいて、その意味では羨しかった。
日本のメジャーな8ビット機では6502が使われないのにカセットで
遣り繰りしてたから。某F社も標準で表計算アプリを添付してたけど
折角FDDを買ったのにデータの保存先はカセット限定とか。

尚、自分はMAC使いではないけどMAC使いで技術力の凄い人はいる。
HAL研から任天堂に移籍し社長になったけど若死にした方とか。

684 ：ナイコンさん：2021/05/31(月) 11:41:52.69 .net

>>682
当然「8bit CPU」限定ではなく、スレタイにあるCPU（MPU）との比較かな。
また今のCPUと比べても意味ないでしょ。

「6809も向いてるようで動作速度として結局は余り向いてない」と言う内容を
具体的に語ってもらわないと単なる>>681氏の思い込みって結論になる。

685 ：ナイコンさん：2021/05/31(月) 11:42:18.99 .net

>>682
8bitとして
6502系なMELPS740がC言語開発で使われるのが国内ではメジャーだった

686 ：ナイコンさん：2021/05/31(月) 12:30:15.97 .net

>>677
68000だって12だか14クロックだか、かかるぐらいの処理だろ
善戦してないか?

687 ：ナイコンさん：2021/05/31(月) 13:30:28.89 .net

>>686
68000はオフセット付けると2ワード命令だから命令読むだけで８クロック＋データをメモリから読んで４クロック
12クロックのd16(An)アドレッシングはいったい何時アドレス計算してるんだろ
あのデカさは伊達じゃないってことか

688 ：ナイコンさん：2021/05/31(月) 16:59:12.79 .net

>>686
12サイクルやね

>>687
> 12クロックのd16(An)アドレッシングはいったい何時アドレス計算してるんだろ
アドレスはS2サイクル（２回目のクロック立ち上がり）で確定することになってるからS0サイクルで計算してると思う

ちなみに6809だと LDA d8,x で5サイクルなので>>681は一体何が遅いと言ってるか興味あるわ

689 ：ナイコンさん：2021/05/31(月) 17:06:17.80 .net

メガドライブの68000版スーパー大戦略のシミュレーション速度は良かったね。一生遊べる。

690 ：ナイコンさん：2021/05/31(月) 17:53:53.38 .net

全然関係ないけどPC-Engineの「ネクロスの要塞」で
HPだったかレベルだったかを512（511だったかも）より上げてからパスワードを保存して再開すると、
512から始まってしまうバグというか仕様があった。
6502コアだからってことはないとは思うけど、その状態でもゲーム自体はできた。
もっと前のレベルでクリアはできるので、そこまで上げる暇人がいるとは考えてなかったのだろうか。

691 ：ナイコンさん：2021/05/31(月) 18:06:58.39 .net

メガドライブを自分も持ってるし嫌いじゃない上、キーボードや2.5FDDを発売する予定と
言ってたので楽しみにしてたけど、期待は裏切られた。とは言え今なら開発環境があるので
46才から趣味でプログラミングの習得を始めて「ダライアス」と言うゲームを移植した人が
いると言うから驚き。スレタイから逸脱するから、この程度でやめるけど。

692 ：ナイコンさん：2021/05/31(月) 20:32:13.59 .net

>>688
クロックが遅い

693 ：ナイコンさん：2021/05/31(月) 20:43:22.93 .net

>>692
2MHzの5クロックと4MHzの15クロックなのに？
算数できないのかな？w

694 ：ナイコンさん：2021/05/31(月) 20:58:25.50 .net

更に2MHzの6809と4MHzのZ80は処理能力が同等と言われてなかったか。
トランジスタの数が8086に迫るから当然かも知れないけど。

695 ：ナイコンさん：2021/05/31(月) 21:15:19.18 .net

6502は誤爆上等とアドレスが間違っていても構わず読みにいくいい加減さが速さにつながるんだが
書き込みで見込みアクセスはできないから1クロック多くなるのが悩ましい

696 ：ナイコンさん：2021/05/31(月) 21:29:44.20 .net

ボクのPC88は8MHzやねんw

697 ：ナイコンさん：2021/05/31(月) 21:33:17.20 .net

今度はZ80叩かれたら68000の話になってる。もはや68kを自慢したいだけだな。
8bitスレで暴れるMIPS君と変わらない。

698 ：ナイコンさん：2021/05/31(月) 21:41:22.13 .net

アセンブラ開発ならアドレッシング多いよりレジスタ多いほうがいい。
限られたトランジスタの中で開発方針が分かれたが結果としてZ80のほうが好まれたようだ。

699 ：ナイコンさん：2021/05/31(月) 21:49:40.73 .net

Z80は最適化上手い人とそうでない人の差が雲泥だな

700 ：ナイコンさん：2021/05/31(月) 22:18:22.77 .net

>>693
Z80は8MHzでも動く
6809は2MHzでしか動かない
1クロックあたりで複雑な処理ができるが複雑なので高クロック動作できないCPUは遅く、
1クロックあたりでは対した事できない単純回路で高クロック動作できるCPUは速い、って例

701 ：ナイコンさん：2021/05/31(月) 22:21:56.15 .net

>>660
Z80にはあるメモリリフレッシュや、IOポートアクセスは？
6502はメモリマップドIOだからアーキテクチャ違い過ぎる。

>>664
そうですよね、クロックも違いすぎますよね。
PCEのCPUはカスタムで7.16MHzまで頑張ってますが特例。
SFCの65C816も3.15MHｚだったしクロックは遅い。

702 ：ナイコンさん：2021/05/31(月) 22:52:10.29 .net

>>697
いや、話しふっといてあれだけど、今から見たら68000はさほど大したもんじゃないだろ

8ビットの頃より集積トランジスタが多いのをいかして機能的にはそれなりの水準だしアドレシングモードが豊富だけど、速度的にはすごく

小さなプログラムなら8ビットの方が速く動くものさえあるんじゃないかって程度のスピードじゃん

機能面だって、妥協とか制限が意外と多かったしなあ

703 ：ナイコンさん：2021/06/01(火) 00:48:25.23 .net

6502にはC-MOS版があるね。Apple][e用のアクセラレータ　ZIP-CHIPには8MHz版もある。
俺の//cのは４ＭＨz版。高速モードだとゲームが速すぎてゲームにならないので常時2MHz。
役立たずw

704 ：ナイコンさん：2021/06/01(火) 00:53:18.10 .net

>>702
68000には特権モードがあって特権モード中には専用SPが使えた記憶。
特権モードがあったからナンチャッテでもunix系のOSが移植できた。
ちなみに68kなMacintoshでは全て特権モードが常態だとか。アンディい〜お前な〜

705 ：ナイコンさん：2021/06/01(火) 01:18:27.33 .net

>>703
ZIP-CHIP 8MHz demo
https://youtu.be/3yYUeBY9m64

706 ：ナイコンさん：2021/06/01(火) 02:14:24.78 .net

>>701
Z180とかでもバスは結構変えてるからZ80に合わせる意味がどこまであるか分からんが、
リフレッシュの追加はトランジスタ数の差からしたら楽にできる部分だろう

I/Oも256バイトだけなら、
6502系でも組み込み用途で内蔵RAM256バイトだけので外部RAM無し用に、
SPをゼロページ兼用化切り替えフラグ追加なんてのがあったから、
CPU内部での使い分けを外部に出してI/O扱いって手はあるな

ゼロページを、8bitアドレスでアクセスするのと、16bitアドレスでアクセスするのと、
別扱いに切り替えられて、別のとした場合にどちらかをI/Oとして扱うとかで
全部まとめてだと扱いにくいから4分割64バイトごと割り当てくらいなら、
6502そのものを使っててもゼロページにI/O配置してたりもするから、
レジスタ扱いと両立できるか

707 ：ナイコンさん：2021/06/01(火) 07:15:53.78 .net

>>700
必死だなw
int *a = ...;
int b = …;
int c = *(a + b);
とかのちょっとしたコードでもめっちゃ差がつくぞ

708 ：ナイコンさん：2021/06/01(火) 13:50:17.98 .net

>>609
Win95のDOS窓を活用するのにconfig自分で書かずに済ましていたと証言している時点で、お前が一体何を語れるの？って話にしかならんよ

709 ：ナイコンさん：2021/06/01(火) 13:52:42.46 .net

>>607,609.610

Win9xは高度なDPMI環境でもあった訳だが、まあお前ら全員それ知らないでイキってる訳だよな…
ニワカのハンチクが挙ってイキリ。なんなのこいつら…

710 ：ナイコンさん：2021/06/01(火) 13:57:44.69 .net

実際Win95(のDOS窓)は、コンベンショナルメモリ空け環境としても最強の一角だったな
素DOSよりも空けられた

理解できないか
できないだろうなこいつらじゃ

711 ：ナイコンさん：2021/06/01(火) 14:45:38.75 .net

OS/2のDOS環境の方が空きメモリは多かったと記憶している。

712 ：ナイコンさん：2021/06/01(火) 14:46:06.95 .net

Windows時代にDOS窓駆使してたおじさん、遅れて怒りの3連投ww
今でもWindows7とか使ってそうww

713 ：ナイコンさん：2021/06/01(火) 15:09:36.92 .net

ひょっとしたらDOS7使ってたりして

714 ：ナイコンさん：2021/06/01(火) 15:31:25.11 .net

普通の人はそんなもんと格闘する必要ないしな

715 ：ナイコンさん：2021/06/01(火) 15:32:15.84 .net

windows10も使っているが、Linuxも使っている。CUI最高。

716 ：ナイコンさん：2021/06/01(火) 15:42:25.89 .net

Win95のDOS窓はほとんど使わなかったけど
Windows7は使ってはいるし、今またFM-77も。
昔のPCでFDを使う際は、Windows7も手放せない。

717 ：ナイコンさん：2021/06/01(火) 17:55:42.81 .net

>>564
「Apple II」は14MHzをソースとしてCPUやメモリに与えてるとのことです。
ttp://k-igrs.hatenadiary.jp/entry/2018/02/28/215619

718 ：ナイコンさん：2021/06/01(火) 19:12:42.72 .net

68k君とwindows君は他でやれよな。

719 ：ナイコンさん：2021/06/01(火) 19:35:34.33 .net

6809がいくら好率がよくてもz80からの移植ばかりさせられてたからな。
マイナーCPUの運命とはそういうもの。

720 ：ナイコンさん：2021/06/01(火) 20:28:35.10 .net

>>717
本来16MHzを８分周して2MHzで動かせばいいんだけどNTSCに出力するために多少性能を犠牲にして
3.579545MHz x 4 = 14.31818MHz
を原発にするのは当時の定番やね
SEGAのゲーム機やMSXとかでも使われてたみたい

721 ：701：2021/06/01(火) 20:38:58.10 .net

おっと、3.58MHzと間違ってた

>>705
高クロックの6502系はそれなりに年が経ってから。
Z80-8Mhzも結局同時期に出たのは88だけ
PCEの6502系も87年
まあ、高クロック化で延命出来ただけマシだな。
この頃になると16bit

>>706
I/OはX1では64kB拡張の非公式のやり方でVRAM側とメインメモリ側を分けてたから困難だな


>>717
元コメの回答になってないと思うのだが？

722 ：ナイコンさん：2021/06/01(火) 21:27:05.67 .net

>>721
6502系MELPS740が1989年に12MHzって形で年々クロック上がりまくりな世代だったからね
別に1987年で6502系を7.16MHzだからってハドソンが特別とかではなく単にその世代なら当たり前な高速化にすぎないという

723 ：717：2021/06/01(火) 22:50:54.28 .net

>>721
元の質問（>>564）の切っ掛けが「DRAMリフレッシュ」についてです。
＞8080や6502、6809でDRAMリフレッシュは実際どうしてたのだろう。

なので6502を実際に使ってる「Apple II」が参考になればと実装方法を提示しました。
また6809については>>574で応えてます。判った範囲で応えることに問題はないでしょう。

あと残りの下などは判る人が応えれば良いだけでは？
＞6502でDMAってそもそもできるんだっけ。

724 ：ナイコンさん：2021/06/01(火) 22:50:59.82 .net

>>717
リンク先をちゃんと読めば、CPUに供給されてるクロックは、その14MHzを14分周した、約1MHzと明記してあるじゃん

725 ：ナイコンさん：2021/06/01(火) 22:53:24.18 .net

>>721
Z80のI/Oアドレスは、拡張して64KB化しようと目論んだけど自動インクリメントするのが上位バイトだったので拡張を封印して、拡張しなかったふりしたとかじゃなかったの? 憶測だけど。

726 ：ナイコンさん：2021/06/01(火) 22:55:48.95 .net

>>722
そのCPUは、作ってたのはリコーじゃないの?
ハドソンは、統合する周辺機能の仕様策定とかやってたんじゃ?

727 ：ナイコンさん：2021/06/01(火) 23:29:57.64 .net

>>724
君こそ確り読んでるか？ バ○に絡まれてるのかな。最初の質問が「DRAMリフレッシュの方法」だから。
リンク先に「14MHzがクロックソースで（フリップフロップで分周して）CPUやメモリやビデオのクロックを生成する。」とある。
http://k-igrs.hatenadiary.jp/entry/2018/02/28/215619

なので「CPUに供給されてるクロック」と言う内容は正しいけど質問が「DRAMリフレッシュの方法」だから君はズレてる。

728 ：ナイコンさん：2021/06/02(水) 00:09:50.32 .net

cpuとNTSCの周波数を合わせたのはmsxとゲーム機ぐらいで他は非同期

729 ：ナイコンさん：2021/06/02(水) 00:27:02.78 .net

IBM PCって大御所が居るだろ
ISAバスにもNTSC用クロック出してる

730 ：701：2021/06/02(水) 00:48:27.05 .net

>>723
別コメ指摘の通り、DRAMリフレッシュ方法に答えてないという話

AppleIIは以下に有るようにビデオアクセス時に行っているようで特殊例？かなあ
http://k-igrs.hatenadiary.jp/entry/2018/02/28/215619

FCやPCEはSRAMだから不要だし

731 ：ナイコンさん：2021/06/02(水) 00:55:49.11 .net

>>728
6001とかは?
あれもクロックが半端だったような気がするんだけど

732 ：ナイコンさん：2021/06/02(水) 07:41:50.54 .net

>>730
君が応えてないと解釈することは君の考えであり、能力かも知れないけど
AppleIIの「DRAMのリフレッシュアクセス」についてはリンク先に説明がある。
説明や回路図が提示されたら「よく読む」・「実装」などして判るように努力したらと。
それをしないと言うことは、それほど知りたい、理解したいとは考えてないと自分は判断する。
もっとも「Apple II」は「tri-voltage DRAMs.」 とのことなので実装は面倒かも知れない。
ttps://www.reactivemicro.com/product/16k-x-1bit-dram/

因みに自分も可能か否かは不明だが某PCのCPU換装等で6502を多少でも使いたいと考えてる。
DRAMの種類がAppleIIとは違うことが吉となるか凶となるか、まぁ駄目元なので凶でも良いけど。

733 ：ナイコンさん：2021/06/02(水) 12:24:30.32 .net

>>722
MELPS740は間違いを恐れず計算途中のアドレスを果敢に読みに行く6502らしさが無くなっているように見える
組み込み専用だから間違い読み出しは困るんだろうけど

734 ：ナイコンさん：2021/06/02(水) 15:34:36.75 .net

>>721
マニュアルにちゃんと書いてあったから非公式のやり方ではないよ。

735 ：ナイコンさん：2021/06/02(水) 23:43:25.66 .net

高clockと言っても
PCEってファミコンのソフト開発ノウハウを流用しようとして6502選んだんじゃねーの？

736 ：ナイコンさん：2021/06/03(木) 03:28:59.35 .net

ハドソンソフトが好きな命令体系が6502

737 ：ナイコンさん：2021/06/03(木) 05:42:40.05 .net

>>736
俺は>>735説を採る。

738 ：ナイコンさん：2021/06/03(木) 06:20:01.41 .net

C言語の普及、メモリの大容量化。
あくまで対ファミコンしか考えてなかったんだろうな。8bitCPUに固執するなんて。

739 ：ナイコンさん：2021/06/03(木) 09:25:49.68 .net

MELPS740なども基本C言語開発
8bit CPUだからC言語無理なんて事はない

740 ：ナイコンさん：2021/06/03(木) 21:41:43.25 .net

グラフィック強化!! 超高速6502!!
PCE開発した人たちは究極のゲーム機だと有頂天だったろうな。

741 ：ナイコンさん：2021/06/03(木) 22:51:38.16 .net

Amiga500と同時期なのに
PCGスプライト路線はしょっぱいしすぐ限界きた
もっと冒険してほしかった

742 ：ナイコンさん：2021/06/04(金) 01:34:24.40 .net

アーケードゲームを移植するにはPCEはかなり性能不足だったな。

743 ：ナイコンさん：2021/06/04(金) 04:24:50.50 .net

まだ大容量メモリが高くて、グラフィック凝るのは難しいだろ
ネオジオとファミコンとの中間としてキャラクタROMが外付けなゲーム機なら高性能低価格も狙えたろうけど更にスプライト特化でしか無いし
どっち付かずな中途半端なゲーム機としてああなったのは分かりやすい

744 ：ナイコンさん：2021/06/04(金) 13:08:48.79 .net

6502を搭載して、スプライトに特化したと言う指摘は外れてはいないけど
1987年当時としてはファミコンに対抗して一定の需要はあったのでは。

ただし16ビット機になればC言語が一般的に使えるので開発効率は高まり
用途が広がったのにと。尚、8ビットでもC言語は使えるけど普及した時には
遅過ぎた感がある。8ビットはアセンブラ、16ビット機以降はC言語の印象が残る。

745 ：ナイコンさん：2021/06/04(金) 13:44:49.17 .net

ゲーム専用機のゲームがC言語開発で効率上げられるなんてのは16bit機ではまだ無理だったろ
NINTENDO64でアセンブラからC言語に切り替えたのが凄いなんて後々だったのが史実で

746 ：ナイコンさん：2021/06/04(金) 15:02:22.40 .net

まだ無理とは、実現不可能と言う意味なのか、一般的ではなかったと言う意味合いなのか？
「用途が広がったのにと」と言う意味合いはゲーム機限定で言った訳ではないし、
更にC言語開発で効率上げられることは16bitのゲーム機でも実証されたのではと。
このスレでも既にスーファミの晩期ではC言語で開発した会社があったと話題に出た。
まぁ先ずは>>517周辺を読んでくれたまえ。多岐に渡る切り口と見解があるけど。

NINTENDO64は、1996年に発売された家庭用ゲーム機だろう。92年頃に「MOTHER2」
の話としてメールシステムを構築し、C言語を使う決断をした人がいるとあるから。

747 ：ナイコンさん：2021/06/04(金) 15:35:00.56 .net

1992年で画期的なのを1987年には先読みして対応するなんて無意味

748 ：ナイコンさん：2021/06/04(金) 16:12:48.81 .net

パソゲーなら糞ゲー上等だったけどファミコンだと糞ゲーは社運落としたからねえ。
コード生成効率が悪いコンパイラなど8bitゲー商品開発には不向き。外した時の言い訳用か
玩具屋のワゴンセールで二束三文で処分されたファミコンゲー糞山の如しではあったけどね

749 ：ナイコンさん：2021/06/04(金) 17:15:10.71 .net

>>747
長文だと全容が掴めないと言う人がいるけど自分は逆に君の一行は何を言いたいのかサッパリ判らない。

16ビットPCのソフト開発も比率は「松」のようにアセンブラから「一太郎」のような「C言語」に推移して行った。
切り口が時代ではなく8ビットから16ビットなのでゲームソフト開発でもアセンブラから「C言語」に推移したことは必然と言える。
尚、16ビットゲーム機で「C言語」の開発が無理と言う意味が実現不可能と言う意味なら、それもまた史実と違う。
確かに「MOTHER2」の開発でアセンブラから「C言語」に変えるように陣頭指揮をとった方は卓越してたと言えるけど。

750 ：ナイコンさん：2021/06/04(金) 21:51:44.80 .net

機械語扱うこのスレで8bitや16bitでC言語は使えたとかレベル低いこと言われても困る。

751 ：701：2021/06/04(金) 21:52:09.51 .net

>>740
究極とまで思ってなかっただろうよ、
FCよりもっと早く、もう少し色と大きなスプライトが欲しいとは思っただろう。

>>741
冒険したらスーパーグラフィックスの価格以上で現実以上に売れなかっただろうな。

>>742
R-TYPEの方は本家では処理落ちするのもPCEではしないようにできたとも聞いた

>>743
しかも、メインメモリ8kBの100nsもVRAM64kの120nsもSRAM
ネオジオと比べるのは可哀そう、時期も価格も段違い。

752 ：701：2021/06/04(金) 21:52:35.19 .net

>>744
16bit機だとMD位からだけど、SFC時代でもROMもまだ高かったし、今視点の考えは暴論では？

>>748
6502に毛の生えた65C816程度じゃC言語そんなに良くないだろう、
タダでさえクロックも3.58MHzで遅いしメモリバンド幅8bit

>>749
メモリもゲーム機より格段に多いPC基準で話は良くないと思う

753 ：ナイコンさん：2021/06/04(金) 22:28:00.45 .net

ゲーム開発はあるゆることでチートができる。
描画でも弾道計算でも思考ルーチンでも厳密に計算する必要はない。

754 ：744：2021/06/04(金) 23:35:25.60 .net

>>752
＞16bit機だとMD位からだけど、SFC時代でもROMもまだ高かったし
＞メモリもゲーム機より格段に多いPC基準で話は良くないと思う
だから「用途が広がったのにと」と言う意味合いはゲーム機限定でないと>>746で言ってるし
また、当時でも4Gビット（＝512Kバイト）と言うROMが搭載されていたので今の視点でない。
その少し前はOS（DOS）の販売会社の社長が640KバイトあればPCのメモリ量として十分と言ってた。

更に>>746で「SFCで、C言語で開発した会社があった」と例を提示してるので、前後のレスを見もせず
妄想で語らいないでくれ。

755 ：701：2021/06/05(土) 00:17:29.30 .net

>>754
元の744の話ではゲーム機(PCE)だったろ？
Cの例もスーファミ晩期と自分で言ってるぐらい、ROMが大容量でも安くなってきてのこと
SFCより数年前に出た機種にSFC晩期の例で言うのは後知恵で今の視点
640kBはRAMでメインメモリだよ、ゲーム機のROMと容量比較はおかしい

「SFCで、C言語で開発した会社があった」としても晩期で一般的でも無かったのだから
メモリも処理速度も不足しがちの環境の為、Cによる開発には不向きのマシンだったって事
条件が良ければ、妥協すればC言語で開発位出来て当然
売れて、儲かる条件が揃ったと判断できたからやっとC開発する所が出ただけ。

756 ：ナイコンさん：2021/06/05(土) 08:42:38.59 .net

C言語、C言語言う人はアセンブラができなくてコンプレックス抱え込んでる人だと思う
アセンブラは大変なだけで難しくないし、デバッグの時にも使えるから覚えればいいとは思う
今の若い人達は覚えることが多いのでアセンブラまでは手が回らないのかもしれないが

757 ：ナイコンさん：2021/06/05(土) 08:57:46.45 .net

>>755
君な、「起承転結」は知ってるよな。>>744の2つ前のレスから
アーケードゲームの比較でPCE、ネオジオの話は既に出ていて>>744では
「承」としてPCEはスプライト特化したマシンと言う事を認めていて、
次に「転」として16ビット機になれば（なった直後でなくも）C言語が一般的に
使えるので開発効率は高まり、用途が広がったのにと言う話の展開なんだけどな。

＞Cによる開発には不向きのマシンだったって事
16ビット機なればと話を「転回」してるのに何故PCEの話限定になるのかと言う理解力がひど過ぎ。

尚、>>752の「MD」と言うのが「メガドライブ」のことならスーファミと同時期に
1991年12月にはCDROMまで発売して大容量の6メガバッファRAMを搭載とあるから
ビットをバイトにしてもRAMだけで「768Kバイト」になるので下もトンチンカンで訳が判らない。
＞640kBはRAMでメインメモリだよ、ゲーム機のROMと容量比較はおかしい

更には何回も繰り返すが、スーファミの晩期とは言えC言語で開発した会社が存在した以上
「今視点の考えは暴論では？」ではないな。当時既に考えた人がいるのに何故「今視点」になるのか？
1990年前後にPCでは「C言語」開発が一般的なっていたのでゲーム機も間をおかず追随すると考えてた。
もちろん君が全然予測がつかなかったと言うのであれば、それはそれで構わない。責めたりしないから。

758 ：ナイコンさん：2021/06/05(土) 09:23:29.42 .net

C言語を書ける奴でアセンブラができないってのは、できないのではなくやってないから知らないだけ
理解できなくてコンプレックスを抱えるなんてあり得ないから

759 ：ナイコンさん：2021/06/05(土) 09:28:16.89 .net

>>757
メガCDはバッファROMたくさん積んでたことや強力なCPUを本体のと別に積んでサブCPUとして使ったりと、非常に意欲的なハードで値段が高かったから、普及してない
当時は標準速150KB/sがメジャーだったなかで、ひと足早く倍速300KB/sのCD使ったのも影響してたかも

数年後に出た価格改訂版のメガCD2以後に普及してるから、そちらの発売年で考えるべき

なお、メガCD増設してない素のメガドラのバッファRAMは、さほど大容量ではない

760 ：ナイコンさん：2021/06/05(土) 09:32:46.50 .net

アセンブラは中学で、Cは高校で。だってコンパイラ高くて買えないんだもん。

761 ：ナイコンさん：2021/06/05(土) 09:49:37.41 .net

>>757
1990年よりも後に企画化されて作られたゲーム機はC言語開発前提で作られてた
1990年以前に企画化されてたゲーム機はC言語前提に作られるのは無理だった

762 ：ナイコンさん：2021/06/05(土) 09:53:47.80 .net

セガが偉いなあと思うのは、マークIIIにFM音源を拡張できたり、
マスターシステムにカード型ソフトを使えたり、
メガドライブ(68000)にマークIIIマスターシステムのソフトをサブCPU(Z80)が実行できるメガアダプタを出したり、
メガドライブにSH2デュアル増設してサターンに近い性能のスーパー32Xを開発したり、

といったところ。感動するよ。経営ロスは大きかったかもだが。

763 ：ナイコンさん：2021/06/05(土) 10:15:04.61 .net

FM7のCライクなコンパイラが雑誌にのってて
頑張って打ち込んだ記憶

764 ：701：2021/06/05(土) 12:05:06.27 .net

>>757
起承転結のつもりで話をずらしてるの誤魔化してるだけじゃないか

＞ただし16ビット機になればC言語が一般的に使えるので開発効率は高まり
＞用途が広がったのにと
これ、広がった「のに」と言ってるから「PCEが16bitだったら」と読めるだろ
後の16bitマシンでということなら、MDやSFCからになるが、それでも大分後でレアな位
「C言語が一般的に使える」に至らなかったぞ
実用になったのはPS,SS時代じゃないか？

メガCDの話は登場時期や値段を考えろ、更にCPUもメモリも本体以上のを追加している

>>759
メガCDはCD等速だぞ。倍速は3DO,PS,SSから、
ネオジオCDは容量バカ食いの癖に等速のアンバランスマシン。CDZで倍速にしたらしいが

765 ：ナイコンさん：2021/06/05(土) 12:10:44.54 .net

今はいい時代になったよな
フルセットのCコンパイラが無料で使えるのが当たり前になってるから
だからアセンブラやろうなんて気にもならないのだろうね

766 ：ナイコンさん：2021/06/05(土) 14:04:11.23 .net

この時代に普通にC使えたという奴は他のスレで散々嘘つきだとバレてるのでCのは話はもういいや。

767 ：ナイコンさん：2021/06/05(土) 14:41:48.87 .net

横レスだけど、Cで開発したせいで反応が悪い、動きモサモサなクソゲーは結構あった気がする

768 ：ナイコンさん：2021/06/05(土) 14:43:18.40 .net

>>764
そうなのか

メガCDのソフトに馴れてからPCエンジンCDROMROMのゲーム遊んだとき、読みこみが遅くて速度差が大きかったから、てっきりメガCDは倍速だったのかと勘違いしてたわ

769 ：ナイコンさん：2021/06/05(土) 15:24:58.04 .net

>>756
> C言語、C言語言う人はアセンブラができなくてコンプレックス抱え込んでる人だと思う
このスレでそんな奴は少ないと思うぞ…

770 ：ナイコンさん：2021/06/05(土) 15:33:02.47 .net

>>765
それ以前に今のx64のアセンブラなんて常人に組めるようなもんじゃない
arduino とかでないと難しいと思う
そういう意味で昔よりハードル上がってるかも

771 ：ナイコンさん：2021/06/05(土) 15:54:54.42 .net

Raspberry Pi PicoのPIOのアセンブラ、オシロ見ながらタイミング合わせるの楽しい

772 ：ナイコンさん：2021/06/05(土) 16:03:44.35 .net

>>770
そかな、x64でも、単に動けばいい程度なら、組むこと自体は（小さいルーチンなら）難しくないと思う

機種別の作りわけとか、最適化ガイドの通り最適化しようとしてからが苦難の本番では?

773 ：ナイコンさん：2021/06/05(土) 18:43:02.88 .net

今どきのWindows10で AH=2, DL=ASCII char, int 21H とかのDOSコールだけの
COMファイルはまだ走るんだろうか？　command.com互換環境があれば
MASMなコードいくらでもアセンブルできるよねえ

774 ：ナイコンさん：2021/06/05(土) 19:16:37.85 .net

アセンブラで人間が書いたのがコンパイラ使うより良いコードだったってのは16ビットまでぐらいじゃね？
x86でも32ビット以降はコンパイラで吐いたコードのほうが人間がひっしこいて書いたのより良いコードの事のほうが多いだろうし。
だけど8ビットでも、不可能だなんてデタラメ言うのがいるが、Cがまったく使われてなかったわけじゃないからな。
容量制限の厳しいROMに突っ込むのにC使うのは正直リスキーだとは思うが。

775 ：701：2021/06/05(土) 21:15:49.89 .net

>>768
あらためてWikipedia見るとCLVでなくCAVと書いてあるの見て驚愕したが、
他情報探してると
PCEのがランダムアクセスが出来ない(そうだったのか？)のに対して、
メガCDは出来るという事を勘違いの可能性

どっちも現物使用したことがあるが、メガCDの方が早く感じる
PCEのが遅いのは速度調整の時間やヘッドの移動時間かな？
やっぱりメガCDの方がメモリが多いのでロードが減らせるとか
メガCDはCD操作しながらゲーム継続出来ているのが大きいかと

776 ：ナイコンさん：2021/06/05(土) 21:33:36.09 .net

>>774
知ったかはもういいから。

777 ：ナイコンさん：2021/06/05(土) 22:11:12.71 .net

>>752
65C816は最初から8MHz品あったよ
おそらくSRAM専用だろうけど
あと6800系は2クロックでメモリアクセスするから3.58MHｚでも8086系だと7.16MHzに相当する
ＳＦＣが3.58ＭＨｚ採用したのは遅いROMに合わせたのと安いRAM使うためだろう

778 ：ナイコンさん：2021/06/05(土) 22:53:34.66 .net

パイプラインとか並列処理でやっとれん
コンパイラ頑張ってくれになったな

779 ：ナイコンさん：2021/06/06(日) 00:15:10.33 .net

>>773
x64版のWindowsは16ビットコード動かす用のサブシステムが削除されてるからなあ
無理だろ

780 ：ナイコンさん：2021/06/06(日) 00:18:28.69 .net

>>773
DOS窓で16bitコード走るのはXPまでみたいよ
知らずに10の32bitモードで動かそうとして駄目だった
今やるならVMにXPかDOS入れてやるかMSDOSエミュレータ
みたいなのも有ったような

781 ：ナイコンさん：2021/06/06(日) 00:24:05.99 .net

>>775
PCエンジンのCDはCDROMのソフト的な規格が固まる前に独自に作ったせいでランダムアクセスしにくい仕様だったのかな、たぶん。
普通のCDROMとは全く異なったフォーマットなのは間違いない

あと、コストの関係かサブCPU使ってないんだろうか、よくわからんけど、アクセス中はCPUがロードにかかりっきりになってる印象
頑張ればロード中画面の簡易な小型アニメを動かしたり音楽流したりはできるけど、その程度でも工夫が必要なのか、対応できてないゲーム多数なぐらい
対するに、処理の多くをサブCPUに丸投げできるメガCDではメインCPUがゲーム処理してる間にディスクからバッファRAMに読み出しておくことができるので、どう考えても速度差があるはず

782 ：ナイコンさん：2021/06/06(日) 04:09:44.01 .net

8bitCPU+CDROM。バランス悪すぎ。16bitCPUでもオーバースペック感がある。

783 ：ナイコンさん：2021/06/06(日) 04:22:11.74 .net

しょせんは1倍速CD-ROMにすぎないんでそれほどじゃない
そんなのが負担なら52倍速CD-ROMを32bit CPUで扱えてたのがオーバースペックだったになってしまう

784 ：ナイコンさん：2021/06/06(日) 05:48:54.15 .net

つまりすべての読み込みに1時間とかかかるわけだな。

テープ時代かよw

785 ：ナイコンさん：2021/06/06(日) 06:54:29.41 .net

>>780
NTVDMを有効にしてもダメかな？
Win16アプリは動くみたいだけど
https://www.ka-net.org/blog/wp-content/uploads/Windows10_OldApplication_02.jpg
https://www.ka-net.org/blog/?p=5959

786 ：ナイコンさん：2021/06/06(日) 06:55:53.07 .net

PCEのCDROMって中身がWAVEでないのを無視すれば楽曲用のCDだしランダムアクセスには弱いんじゃなかろうか？
あとドライブの性能も関係するだろうし。

787 ：ナイコンさん：2021/06/06(日) 07:07:38.37 .net

ショボイ8bit機でそんな大容量何に使ってるのか思ったらWaveデータに使ってたのか。
WAVEファイルも8bitCPUじゃまともに処理できないから結局ハードに丸投げだったのかな。

788 ：ナイコンさん：2021/06/06(日) 07:45:10.74 .net

8086⇒子孫 Core-i系　Ryzen系　
6809⇒MC68060で断絶
6502⇒ARM?
Z80⇒80年代に断絶

789 ：ナイコンさん：2021/06/06(日) 07:58:57.55 .net

>>766
ありえないスレでぼろ負けしてこっちにまで出てきてもお前に勝ち目はないぞｗ
嘘とでたらめを並べたいならありえないスレでやってろよｗ

790 ：ナイコンさん：2021/06/06(日) 08:14:28.03 .net

>>789
Cでの開発環境聞かれただけで逃亡した嘘つき君ですね。

791 ：ナイコンさん：2021/06/06(日) 08:32:36.45 .net

日本でC言語が注目を浴びるようになったのは故石田晴久先生監訳の
K&Rのプログラミング言語Cの翻訳本が出た後。81年7月以後のこと。
8001が79年晩秋発売だから少なくとも2年間のブランクがあったですね。
その2年の間でC言語を使えた人って石田先生見ないな研究者かPDPで
あえてunix起動していた人。bit誌周りに若干居たくらい。

792 ：ナイコンさん：2021/06/06(日) 08:43:21.82 .net

>>787
16bit CPUでも楽な処理じゃ無かったからCD-ROMからオーディオ出力をサウンドカードに繋いでたよな
https://diarywind.com/blog/e/connect-cd-drive-and-sound-blaster-cdin.html

793 ：ナイコンさん：2021/06/06(日) 08:51:02.78 .net

>>790
そうそう、CP/M-80 + HI-TECH C とか出されて遁走したんだよな

お・ま・え・が w

794 ：ナイコンさん：2021/06/06(日) 08:53:13.71 .net

>>793
あ、それってオモチャですから〜　残念

795 ：ナイコンさん：2021/06/06(日) 09:01:58.56 .net

8bitCPUでCは普通に使えたという話なら隔離スレあるからそっちでやってくれ。

796 ：ナイコンさん：2021/06/06(日) 09:24:07.48 .net

>>794
HI-TECH C 知らんの？
まじでちょっと恥ずかしいぞ
まあ恥の概念あったらわざわざ劣勢なのに粘着しないかw

>>795
すまん、ちょっとからかってみただけ

797 ：ナイコンさん：2021/06/06(日) 09:40:09.54 .net

>>796
おまえのための隔離スレだが。

798 ：ナイコンさん：2021/06/06(日) 10:48:15.13 .net

>>795
あのスレの存在理由が判らなかったけど、このスレの「隔離スレ」だったのか。

＜朝から日記＞
アセンブラは6809しか判らなかったけど最近6502にも興味を以て、このスレでレスをしたら
様々な意見・批判が飛んできて困惑した。背景は「8ビットのC言語」の影響なのか。
「8ビットC言語」も1987年当時までなら学習を兼ねて使いたかったが3800円の時は購読してた
情報誌には見当たらなかった。それぞれの「C言語」に支援した背景があるのかも知れないけど
1987年と言えば32ビットも見えていたので結局6809はアセンブラ、MS-DOSからは「C」だった。

なので「8ビットはアセンブラ、16ビットはC言語」に対し、「俺は16ビットでもアセンブラだ」
「いやいや、俺は8ビットでもC言語だったな」と言うレスを予想したけど事実は奇なりと。

799 ：ナイコンさん：2021/06/06(日) 10:49:49.72 .net

>>798
おまえを隔離するためのスレだよ。

800 ：ナイコンさん：2021/06/06(日) 11:20:51.13 .net

そんなにゲーム開発にC言語が使われてたなら
なんでC言語に向かない6502なんて使われたんだろうな
C言語での開発がメインならもっとC言語向きのCPUが使われてたはず

801 ：ナイコンさん：2021/06/06(日) 11:26:26.14 .net

昔のPC板で8bitの話をすると1970年代、1980年代ではなくて
PICとかAVRとかの話をしてくる奴いるよね

802 ：ナイコンさん：2021/06/06(日) 11:38:22.48 .net

>>800
MELPS740はC言語での開発メインで大量に使われてたんだから、向かない6502を使うのは関係ないな

803 ：ナイコンさん：2021/06/06(日) 12:15:20.49 .net

高級言語はソフト開発の再生産性が改善するよね。
8ビットはまだアセンブラのコードが職人技でできたから、広まらなかったのかと。
最初に添付するソフトがCP/Mだったら違ったかもしれませんね。
X68000の開発環境でセグメント管理いらなくて感動しました。

804 ：ナイコンさん：2021/06/06(日) 12:27:22.62 .net

大きなオーバーヘッドが許されるなら何でもあり
AoSからSoAへの構造体書き換えとかは許さん

805 ：ナイコンさん：2021/06/06(日) 13:05:59.33 .net

8ビットもセグメントはなかったんじゃぁ(スレタイの一部から微妙に目をそらしつつ)

806 ：ナイコンさん：2021/06/06(日) 13:30:41.64 .net

x86のリアルモードでセグメントが面倒とか複雑とか思ったことないな。

807 ：ナイコンさん：2021/06/06(日) 13:33:50.33 .net

まあ、8086リアルモードのセグメントは80286ネイティブモードのセグメントと比べたら単純だったしな

808 ：ナイコンさん：2021/06/06(日) 13:35:56.96 .net

>>802
また、マイコンの話かよ

809 ：ナイコンさん：2021/06/06(日) 13:39:52.60 .net

マイコンなんてC言語全盛の今でも8bitでシェアが高いのはC言語に向かないPICだろ？
1980年代の8bitパソコンやゲーム機のように
能力を100%出し尽くさないといけないのとはわけ違う

810 ：ナイコンさん：2021/06/06(日) 13:53:09.47 .net

能力を100%出さなきゃならないからC言語を使える余力が無かったってだけだろうな
C言語に向いてるメガドライブが、発売当初からC言語で開発効率高くてスーファミよりも有利だったなんて話は無かった

811 ：ナイコンさん：2021/06/06(日) 15:38:22.26 .net

開発はmsdosなので効率の良いコンパイラがあったかも

812 ：ナイコンさん：2021/06/06(日) 15:50:47.23 .net

ゲーム開発用にintしか使えないBASICとそのコンパイラみたいな環境でも有れば楽々で捗ったろうにな

813 ：701：2021/06/06(日) 20:35:09.25 .net

>>781
PCEのCD-ROMはSCSIだった事や、インターフェースユニットにもCPU無さそうなので
CPUが処理する等で、効率的に使えてなかったのでは？

>>782
目的は高価になっているROM対策と、グラフィックの多用、サウンドが弱いのでCDDA活用辺り
そう悪いとも言えないのでは？

>>784
上に書いたようにデータとして全部使い切る前提とも言えないので問題ないでしょう。
最初のメモリ容量は少なすぎたが、2Mbitで良い感じに。
これでも連続読み込みなら数秒で満たせ、CD内容を全部オンメモリに持てないのだから的外れ

814 ：701：2021/06/06(日) 20:39:55.02 .net

>>786
>>787
音声データにも使われたけど、メモリもPCM能力も貧弱なのでBGMをCDDA再生などで良く使われてる

815 ：ナイコンさん：2021/06/06(日) 20:46:01.73 .net

dmaを使えば良かったのにね

816 ：ナイコンさん：2021/06/06(日) 22:17:58.00 .net

SCSIだったのか。
NECブランドなんだし88のFDやHDのようなインテリドライブ方式かと思ってた。
88MCにPCEのCDドライブくっついてたし。

817 ：ナイコンさん：2021/06/08(火) 00:41:49.52 .net

PCエンジンのCD-ROMドライブってほんとにSCSIなの?
PCエンジンのCD-ROMドライブをSCSIに変換するアダプタの
発売予定があったとか、SCSI経由でパソコンにつなぐデモが
あっただけなんじゃないの?
PCエンジンとCD-ROMドライブの接続をSCSIにする必然性が
まるでない気がするのだけど
PC8801-30とか31の詳細がわかれば判明すると思うんだけど
全然情報ないなあ

818 ：ナイコンさん：2021/06/08(火) 00:48:00.69 .net

昔のCDROMドライブはHDDと同じSCSIインタフェース

819 ：ナイコンさん：2021/06/08(火) 05:46:59.68 .net

>>817
WikipediaではSCSI-1ってなってるね
https://ja.m.wikipedia.org/wiki/CD-ROM2

820 ：ナイコンさん：2021/06/08(火) 10:12:21.90 .net

>>817
大体>>819に書かれてる
書かれてない情報としては、PC-88もCD-ROMは内部的にSCSIコマンドを発行してコントロールしてる

821 ：ナイコンさん：2021/06/08(火) 10:32:28.42 .net

>>820
内部的？
PC-8801用のCD-ROMドライブはPC-Engineの奴と同じだよ
NECもPC-8801のカタログにPC-EngineのCDR-30がつなげるよ！とか書いてるし
https://akiba-pc.watch.impress.co.jp/img/ah/docs/1294/386/html/apc8801mc5.png.html

822 ：ナイコンさん：2021/06/08(火) 13:04:47.27 .net

MC2内蔵ドライブでも、ROM2のドライブでも、内部ではSCSIコマンドでコントロールしていますよ、BIOS内部で、ってことでは？

823 ：820：2021/06/08(火) 15:12:59.21 .net

ああごめん、上のほうの「88だからインテリジェントタイプのドライブじゃないのか？」に対して
メインCPUが直接駆動してるよ、のつもりだった
内部的ってのは>>822さんの補足の通り
用意されてるCD-BIOSでそうなってます

824 ：ナイコンさん：2021/06/08(火) 18:30:48.23 .net

たぶん、最初に作られたリファレンスのCDROMがSCSIタイプだったので、それを援用したとかではないかな?

少し遅れるが、IBMPCの互換機界隈でのCDROMはSCSIは早期に廃れて専用インターフェースのが普及したんだよな、IDEもどきな感じ? のやつ

825 ：ナイコンさん：2021/06/08(火) 18:47:23.60 .net

外付けはscsiでは

826 ：ナイコンさん：2021/06/08(火) 18:48:48.73 .net

ATAPIなCDドライブといってもハードウェアのデータハンドシェークがATA系というだけで
操作コマンドはSCSI踏襲でしょ。というか、CD-ROMがややこしいのは元々が音楽再生
デバイスでヘッド移動を緩やかにするためにセクタの並びがスパイラル。同心円トラック
じゃないのね。その点でスパイラル系のHFSと馴染みやすい。
ファイル管理の論理形式もAppleのHFS、ハイシエラHSFから ISO-9660と標準化が
進んでさらに音楽CDのCD-DAやCDI、CDVとかそれらの服号同居系とか面倒この上ない代物。
30年前にmac向けのCD-Rのライターアプリの開発に関わったことあるけど。面倒杉でorz

827 ：ナイコンさん：2021/06/08(火) 18:56:06.41 .net

>>825
まあ、IDE系は内蔵デバイス専用だしね

最初のはサウンドカードに搭載のCD専用インターフェース。
少し遅れて、IDE第2系統バスに置き換わってIDE接続CD
んで、IDEの規格を再拡張してATAPIが出たんじゃなかったかな

828 ：ナイコンさん：2021/06/08(火) 19:53:45.73 .net

AT互換機はSCSI・ATA・MKE(SoundBlasterに付いてたCD-ROMインターフェース)
が並び立ってた頃もあった

829 ：ナイコンさん：2021/06/08(火) 21:28:21.00 .net

>>826
2000年頃に叩き売りされていたPC-98用の「PC-FXGA」はSCSI仕様のCDROMが必須となってた
記憶があるけどATAPIでも使えたのは、そういうことですか。

>>828
確かにISAのSoundBlasterとAdaptecのSCSIコントラーが搭載された基板がありました。

830 ：ナイコンさん：2021/06/09(水) 00:38:10.96 .net

scsi付きSoundBlasterね。あったあった。

831 ：ナイコンさん：2021/06/09(水) 08:36:20.31 .net

SCSI付とは別にCD-ROM専用インターフェース（Panasonic CD interface）
が付いてたSB16もあったよ

832 ：ナイコンさん：2021/06/09(水) 12:01:56.80 .net

それはいちばんポピュラーなやつ

833 ：ナイコンさん：2021/06/09(水) 12:06:47.02 .net

おれにとってSCSIは黒歴史。

834 ：ナイコンさん：2021/06/09(水) 12:27:41.78 .net

>>828
＞CKK さん
Posted in 1998-09-23 07:58:00

＞MKE I/Fって、結局どんな物だったのでしょうか？
よく知らないので詳しい方、解説をお願いします。IDEの変種でしょうか？
＞1. Reply: MKインターフェース
ks18w0f13.jaist.ac.jp


＞Ｔｏｐｉｋａ さん
＞Posted in 1998-09-23 10:56:00

＞ATAPI規格ができる前の、CD-ROM専用規格のI/Fです。
昔はSCSI以外のCD-ROMは、専用I/Fと一緒に売ってました。(PC/ATの話)

＞その中で有名なのがSONY規格、MITSUMI規格、もう一つがMKE/Panasonic/Creative規格です。
＞MKEってのは松下寿電子(Matsushita Kotobuki Electric)の略称ですね。

つまり、IDE／ATAPI以前のCDROM専用インターフェースは三種類あったのか

835 ：ナイコンさん：2021/06/11(金) 00:41:05.87 .net

ソープランドがキャバクラになって、ガールズバーなんだけど、酒場の話になるの
そしてバーボンよりウォッカの方が好みだ、いや夏はビールでしょ？の話題でいつもいつも盛り上がるんだな

836 ：ナイコンさん：2021/06/11(金) 00:54:38.98 .net

なんかさー、俺たちバスケとサッカーなんだけど、たまに野球やるよな？仲間に入れようぜー
えー、でもバット使うじゃん？？
いいからいいから、ボールなんだしぃ

最近さあ、テニスどころかバドミントンもやる奴増えたよな
バドミントンってシャトルだし、ボール関係なくね？

837 ：ナイコンさん：2021/06/11(金) 00:59:41.21 .net

なんかさー、詳しいらしいよ、相撲に
解説者になれるぐらいらしいよ
話し上手で頭いいらしいね
えー、それって頭いいって言うか、オタクなんじゃないの？相撲の
いいからいいから、自分たちでは頭いいと思ってんだから
オタクだから、ほっときましょ
話だけで、相撲取れない奴もいるだろうし

838 ：ナイコンさん：2021/06/11(金) 02:39:36.81 .net

ドフでたまにDsub60位のコネクタ付いたCDROMあったがあれかな

839 ：ナイコンさん：2021/06/11(金) 07:31:57.25 .net

SCSIの外付け型はD-SUB50だけど、内蔵用のでD-SUB使うことはないのではないかなあ

SCSI2以後に主流になっていく小型D-SUB系統のコネクタはCDROMに採用されるのが遅くて、長く標準サイズD-SUB50が使われてた気がする

D-SUB60は、そんなん使われてたのかなあ?

840 ：ナイコンさん：2021/06/12(土) 23:15:03.91 .net

えらく脱線してるなｗ
ＳＣＳＩにD-SUBはMacintoshくらいしかないんでない？
非平衡SCSIは結構見たことあんけど、98シリーズやWindows機はアンフェノールとその派生ばかりだった。

841 ：ナイコンさん：2021/06/13(日) 12:19:41.77 .net

ごめ、オレの返答が記憶違いだな

マックのがD-SUBの25ピン、
SCSIの基本がアンフェノールの50ピン、
少し後のSCSI2時代の主流が98用とかではアンフェノールのミニの50ピンになったのに対してAT向けのSCSI2のはミニD-SUBの50ピン

その派生でワイドSCSIの68ピンがあったわけだから、ミニD-SUB68ピンってのならあるんじゃないのかな

842 ：ナイコンさん：2021/06/13(日) 12:21:46.01 .net

書き忘れたけど、オレ841の記憶間違いと言ったレスは839のことな

843 ：ナイコンさん：2021/06/13(日) 13:46:53.99 .net

>>841
そそ。そんな感じだったね。そのほかに若干異端もあったけどね。
ICMのSCSI外付けが確かハーフピッチの50pinD-Subだった記憶。
あとATARIのmegaSTのSCSIはACSIという別名のSCSIサブセットで21pinD-SUB。
Amigaのビデオの23pinD-SUBと双璧をなす変態コネクタだったなあ。入手困難。
困りものはzipドライブ本体の25pinメス。98のミニや互換機のミニ系と
ノーマル25pinD-SUBのケーブルを用意するのが面倒だった。ただzipドライブは
よく出来たドライバーのおかげで他機種ファイルを混在できたような記憶。

844 ：ナイコンさん：2021/06/13(日) 19:19:20.60 .net

ICMにはD-Sub37ピンのSCSIもあったよ

845 ：701：2021/06/13(日) 20:14:22.21 .net

高速6502→PCE→CD-ROM2→SCSI
と話を脱線させてしまった。

スレタイの話題に戻すために話題をふる
・アメリカでは6502が初期PCとしてある程度流行ったが、日本は何故Z80ばかりだったのか
・アメリカである程度成功した6502の後継65C816があまり流行らなかったのは何故か
・6809が流行らなかったのは登場が遅すぎたのかクロックか

やっぱり早くから出てそれなりの性能の8086系の互換性とソフトが勝因なのかねえ？

846 ：ナイコンさん：2021/06/13(日) 20:24:20.92 .net

Z80は国内メーカーがセカンドソース品とコピー作ってたから・・・（白目

847 ：ナイコンさん：2021/06/13(日) 21:05:09.33 .net

日本の場合CPUメーカーが同時に家電メーカーで電機メーカーでもあったから
高性能でもは却下だろうね
日本のアップルになれそうだったのはソードくらいか

848 ：ナイコンさん：2021/06/13(日) 21:12:55.50 .net

他社製CPUつかうなんてとんでもない！という風潮があったからな。

849 ：ナイコンさん：2021/06/13(日) 21:22:24.94 .net

>>843
ZIPの25ピンはマックのと同じでしょ

850 ：ナイコンさん：2021/06/13(日) 21:25:41.44 .net

>>848
国内メーカーで自社工場で作ったやつ以外の他社CPU使ってたのって、MSXより前にはほとんどなかったもんな

カシオとソードは違ったんだったか?

851 ：ナイコンさん：2021/06/14(月) 05:25:27.29 .net

6502は安かったんだよ
だからウォズ自分で作ったボードに使ったわけ
モステックの親会社でもあったコモドールも自社のパソコンに使った
ただそれだけ
8080がもっと安ければウォズも8080使ったんじゃないかな？

852 ：ナイコンさん：2021/06/14(月) 05:34:03.46 .net

日本でZ80が流行ったのは
5V単一電源とDRAM用のリフレッシュ回路が内蔵されてたのも大きいのでは？
後発の6809も日本ではそれほど後発でもなかったのと富士通の力があったからだと思う

853 ：ナイコンさん：2021/06/14(月) 10:02:46.25 .net

ウォズは8080なんか嫌いで6800を好んだけど
6502が安かったのでそれにした。

854 ：ナイコンさん：2021/06/14(月) 10:05:35.02 .net

でもウォズのいたずらで発表会で配ったパロディのライバルちらしのスペックはZ80なんだよ。

855 ：ナイコンさん：2021/06/14(月) 10:57:40.67 .net

6800の３倍速いって宣伝された6502があるのに
6800マイコンを売るメーカーはかなりユーザーをナメている

856 ：ナイコンさん：2021/06/14(月) 16:17:11.73 .net

日本の6800パソコンが出た頃には6800はダメって既になってたのにあえて出した変なパソコンだったろ

857 ：ナイコンさん：2021/06/14(月) 17:25:13.21 .net

個人部門は眼中になかったので売れ残りの6800を捌くためにかな。
ビデオにしても役に立たないがサブで6800を使ったポケコンがあったような。

858 ：ナイコンさん：2021/06/14(月) 18:50:45.79 .net

6800を使ったpcはベーシックマスターとJR100ぐらいか
テキストベースなので特に不満は出ないような気が

859 ：701：2021/06/14(月) 20:43:23.92 .net

>>851
その辺は知ってる、6502が初期に流行った理由の一つ。安くて速かった。
同様に日本で自社で作るからZ80が安いとかはあったかもしれないが
6502もファミコンが採用したようにリコーとかが権利持ってたしなあ。
PCで6502などにするにはメモリ少ないゲーム機がSRAMで済ますのと違って
リフレッシュに工夫が要るのも嫌ったのかね？

860 ：ナイコンさん：2021/06/14(月) 21:13:32.58 .net

6502はアップル２みたいな極初期やゲーム機にはいいけど
Z80,6809と出揃ったらパソコンのメインCPUにはやっぱり扱いにくいでしょ
6809が主流になってほしかったな
FM7があんな糞設計じゃなかったらというのもある

861 ：ナイコンさん：2021/06/14(月) 21:47:38.34 .net

6502はホビー機には向くだけでは？

862 ：ナイコンさん：2021/06/15(火) 02:04:46.89 .net

6502はメモリ操作が早いので
画面つくるのにメモリ操作しまくるゲーム用途なら
6502が最強なのは当然なわけで

863 ：ナイコンさん：2021/06/15(火) 03:25:37.97 .net

6502はプロセス技術に合わせた高クロック化出来ててどんどん高速化できてたしな
パソコンとしては互換性重視で初期クロックのままだったりしても、周辺機器として高クロックCPUアダプタが売られてたし
Z80(4MHz)＝6809(2MHz)＝6502(2MHz)な頃には高機能な6809が良い感じではあったが、
Z80(8MHz)＝6809(2MHz)＝6502(4MHz)ってなってしまって6809だけついて来れなかった
Z80(8MHz)＝6809(2MHz)＝6502(6MHz)ってまでパソコンで進んだ時点で8bitでもGUI使うなら6502だなってなってた

864 ：ナイコンさん：2021/06/15(火) 04:15:08.13 .net

8bitレジスタしかない6502なんてメモリ扱う、グラフィック扱うのに一番面倒なCPUだろ。
スクロール、スプライトなどハード支援なければゴミ。漢字も扱うのは不向き。

865 ：ナイコンさん：2021/06/15(火) 05:18:33.44 .net

漢字扱うのに16bitが必要なんて勘違いされててもな

866 ：ナイコンさん：2021/06/15(火) 05:25:34.81 .net

このとおり。6502信者ってほんと自分ではコード書かないのに6502最強って思ってるから話が面倒。

漢字扱うのに16bitいらねっだってさw　技術音痴、馬鹿丸出し。

867 ：ナイコンさん：2021/06/15(火) 06:10:34.05 .net

16bit機ですらハード支援ないと
まともに実用レベルで漢字表示できないのに6502ならできるらしいw

868 ：ナイコンさん：2021/06/15(火) 06:47:17.55 .net

>>856
そもそもスタック256バイトしかないからちょっと大きなソフトは作りにくいだろ
VisiCalcとかよく作ったと思う

869 ：ナイコンさん：2021/06/15(火) 06:55:19.05 .net

> 画面つくるのにメモリ操作しまくるゲーム用途なら6502が最強

寝言は死んでから言え。

870 ：ナイコンさん：2021/06/15(火) 06:55:40.18 .net

6800の開発者のチャックぺドルがなぜモトローラをスピンアウトして
6502開発に打ち込んだかといえば、とにかく安価なCPUを作って売って、
時代の流れを変えたかったから。だそうだ。モトローラ社内には
CPUの意味意義可能性を見通せる経営者マネージャーがほとんど居らず
エンドユーザーに対する売り込みも開発者自ら出張るしか無い状況だった
しかも販売価格は一個300ドル。当時のドル円は激動していたが250-300円位。
一個7-8万円。ウォズニアクが入手した6502は25ドル。
見事な価格破壊者なののよね6502は。安売りは正義だし。チャックは正義の使者。
ベトナム戦争敗戦は1975年。時代を変えようという流れが強い時代だったね。

ただし、半導体開発社は安売りしてはいけない。実際、モステクノロジーは
安売りのおかげで運転資金枯渇で会社自体をコモドールに売却せざるを得なかったわけで。涙。
その点で、インテルは安売りは絶対しないが社是だった。競合他社と価格競争になるくらいなら
デバイスの製造販売を止めて上位デバイスに選択集中。元々メモリの会社だったインテルは
2708-16-32-64とか日本メーカーと鬼ゴッごして追いかけられて負けっぱなしな80年台初頭。
それでインテルは法廷闘争と政治的圧力を併用して市場を制圧し拡大発展できたのね。

871 ：ナイコンさん：2021/06/15(火) 06:56:01.08 .net

長文ですまんね

872 ：ナイコンさん：2021/06/15(火) 06:58:59.63 .net

>>864
ゼロページを16bitレジスタ128個として扱えるから、グラフィックに向いてる方だよ

873 ：ナイコンさん：2021/06/15(火) 07:00:08.15 .net

x 画面つくるのにメモリ操作しまくるゲーム用途なら6502が最強
o ワークメモリ256バイト内のメモリ操作しまくるゲーム用途なら6502が最強

大容量のVRAM操作はマジ苦手。

874 ：ナイコンさん：2021/06/15(火) 07:14:30.32 .net

漢字をまともに表示するなら640x400が必要。白黒な32KBで済むが8色なら96KBのVRAMが必要。
漢字フォントに至っては第一、第二水準で6355文字。16x16だとしても200KBぐらいになる。
これだけ漢字扱うのは負荷高いのに6502でハード支援なしで処理できると思ってるのが6502信者。

ゼロページは16bitレジスタ128個として使えるから強い!!　イタすぎる。
そもそもそんなに強かったらウォズはSweet16なんて用意しない。

875 ：ナイコンさん：2021/06/15(火) 07:25:38.36 .net

Sweet16ができてるってのが16bit扱えるって事そのものなのだが

876 ：ナイコンさん：2021/06/15(火) 07:47:07.45 .net

今度はSweet16があるから16bit扱うことが得意なのか。
自称16bitレジスタが128個だったのにSweet16で16bitレジスタが16個にを減ってるし。

もうAppleII使ったことないのバレバレやん

877 ：ナイコンさん：2021/06/15(火) 07:52:57.53 .net

> SWEET16 runs at about one-tenth the speed of the equivalent native 6502 code.

10倍遅くてもindirectアドレッシング使うより
16bitレジスタをエミュったほうがいいという判断。ウォズはやはり天才プログラマ。

878 ：ナイコンさん：2021/06/15(火) 08:34:19.18 .net

インタープリタだから遅いが、コードを圧縮出来て小メモリで済むからね
これレジスタ数を絞らないとバイトコードに収まらず小メモリ狙いを満たせない

インタープリタだからって、扱えないデータを扱えるようになる訳じゃない
アセンブラでは扱えないデータだからインタープリタで扱うって使い方ではなく、小メモリや開発効率の向上のために遅くなっても使うのであって

879 ：ナイコンさん：2021/06/15(火) 09:48:44.47 .net

もうちょいトランジスタを増やしてインデックスレジスタを16bitにするべきだった

880 ：ナイコンさん：2021/06/15(火) 10:18:56.99 .net

内部バスが8bitではレジスタデータを転送する速度が2倍かかるようになるからねえ
カスタム品や上位互換品は多いが内部バス16bitな65816系でしか16bit化してない
ゼロページを移動させるレジスタ追加などは有るのに

881 ：ナイコンさん：2021/06/15(火) 12:36:14.72 .net

8080にしろZ80にしろ、レジスタの転送時間が2倍になる程度のペナルティなんて問題じゃない扱いでペアレジスタ使ってたけど

882 ：ナイコンさん：2021/06/15(火) 13:00:50.15 .net

6502を「APPLE�U」に搭載した理由は>>870氏が指摘する、圧倒的な安さだろう。
多少使い難い面があっても英語圏で使えれば売れ行きは販売価格に大きく影響する。

>>860
6809は命令体系が判りやすいと考えるがFM-7（FM-8）の設計の悪さはどの辺り？
メインCPU（MPU）では複数の選択肢があり、当時としては画期的な機能・技術でしょ。

883 ：ナイコンさん：2021/06/15(火) 16:25:53.67 .net

6502はZ80がリフレッシュしている間に命令の2バイト目を読んでいて
Z80が上位アドレスの読み込みだけをしている間に下位アドレスとインデクスの加算を行っているから速いのです

884 ：ナイコンさん：2021/06/15(火) 18:56:56.62 .net

半導体を売る側から見ると、顧客のデバイス選択の優先度は
�@単価
�A供給能力。納期の安定性。
�B開発スタッフのスキルと慣れ親しみの度合い。
�Cデバイスの性能。

購入者側からすれば、製品性能が最重要だろうけどね。

885 ：ナイコンさん：2021/06/15(火) 19:05:12.66 .net

>>881
アドレッシングでのアドレス計算に頼れないからレジスタペアを使うしかないって、
命令セットの都合上ではないかな
8bitバスでは不利な処理なのは処理クロック数として現れてたんだから、
避けられるなら避けたいだろうが必要な問題があった訳で
後から割と、幾らレジスタ志向だろうがアドレッシング足りなすぎるだろって言われてるし
まあ、言われるような頃には16bitバス化も出来たんだから、8086と同時に16bitバス化Z80を作るべきだった所

886 ：ナイコンさん：2021/06/15(火) 19:20:06.94 .net

>>885
> まあ、言われるような頃には16bitバス化も出来たんだから、8086と同時に16bitバス化Z80を作るべきだった所
Z8000 …

887 ：ナイコンさん：2021/06/15(火) 19:23:22.93 .net

なんでZ80との互換性を取らなかったのか

888 ：ナイコンさん：2021/06/15(火) 19:37:52.76 .net

8bit CPUと命令（上位）互換の16bit CPUなんてあったっけ？

889 ：ナイコンさん：2021/06/15(火) 19:41:58.28 .net

V30のことかな。

890 ：ナイコンさん：2021/06/15(火) 20:20:30.06 .net

幻のZ280あたりかな。
プロセッサ誌でFM7用ボード作ったようだががあまり早くなかった模様。

891 ：ナイコンさん：2021/06/15(火) 20:21:12.45 .net

それ8080モード

892 ：ナイコンさん：2021/06/15(火) 20:21:26.26 .net

65816とかR800とか

893 ：ナイコンさん：2021/06/15(火) 21:10:48.06 .net

性能高くても使い勝手が悪いと売れない。
それが日本という国なだけ。

8080というか、Z80が売れた理由はそんな単純なことだよ。

894 ：ナイコンさん：2021/06/15(火) 21:13:18.70 .net

>>890
Z280は拡張の方向性が間違いすぎてたな
eZ80のシンプルな正しい拡張の方向を早く出せてれば
eZ80よりもZ280の方が複雑にしすぎてて結局は意味がなかった

895 ：ナイコンさん：2021/06/16(水) 03:20:02.18 .net

>>893
海外では8080,Z80売れなかったん?

896 ：ナイコンさん：2021/06/16(水) 03:50:08.74 .net

8088にさっさと置き換わった

897 ：ナイコンさん：2021/06/16(水) 06:58:50.63 .net

そして欠陥プロセッサ80286を経て80386へ

898 ：ナイコンさん：2021/06/16(水) 10:58:47.61 .net

Amstad CPCとか海外は90年代まで粘ってた
90年にはGX4000というZ80ゲーム機も出してた

899 ：ナイコンさん：2021/06/16(水) 11:05:07.25 .net

組み込みみたいなスキマ需要を求めてeZ80みたいになっただけじゃないの
Z180はそこで多く使われたから命令セットを継承しただけっしょ
PCで使われるCPUと考えたらZ800が間違っていたとは思えないな

900 ：ナイコンさん：2021/06/16(水) 11:44:27.33 .net

>>898
90年前後はベルリンの壁崩壊直後で、東欧一帯でそれまで禁制品だった西側製品
特にパソコンの特需が湧き上がったそうだ。ネット以前だったから8bitパソ。
Atariの800系とかAtariの中の人がなんで今頃東欧でと首をひねっていた話が。
msx とかもロシアでユーザーズクラブができるほど。という噂。

901 ：ナイコンさん：2021/06/16(水) 12:02:23.77 .net

なるほどな。日本も1980年前後はマイコンに憧れて8ビット機を買うマニアックな層がいた。
それが1980年代中盤以降はビジネスで16ビット（大半が98だけど）で8ビットは趣味になり
1995年のWin95で一般に普及した。そして今は周知のように老いも若きも「スマホ」へと。

902 ：ナイコンさん：2021/06/16(水) 16:39:15.42 .net

>>882
>FM-7（FM-8）の設計の悪さ
VRAMアクセスが面倒とか、やっぱテキストVRAMがないのはな〜とか、キー入力が糞とか。
「本格PCには6809を」と思う理由の1つは「ライトなプログラマーにとって書きやすく読みやすいから」なので前2つは6809の良さを殺してる。

6502は書きにくく読みにくく大規模プログラムが作りにくいがゲーム機ならいい。
安くて速いしコード書くのはゴリゴリのプロだけだし1度書いたものをそんな長く保守しないから。

903 ：ナイコンさん：2021/06/16(水) 16:48:09.09 .net

PC88のソフト開発が優先されてからというもの、移植が面倒でFM7系が嫌がらてた感がある。
だから富士通はTownsではメジャーなCPUを選択したのだろう。

904 ：ナイコンさん：2021/06/16(水) 18:48:19.19 .net

6502はやっぱりファミコン時代のこじんまりしたゲームをブン回すには価格性能比最強だったと思う
だけど長大なコンパイラやOSを書いたり動かしたり、
プログラミングのプロじゃない人がプログラムを書くにはRISC的すぎて扱いにくいのではと
また人間向きのアイディアをハードやプログラムにするというよりは
6502というCPUに向いたハードやソフトの仕様を設計すると超効率になるという感じが強い
6809が逆だとすればZ80はその中間で中途半端
だから'80年代が（せっかく6809があるのに）ずっとZ80時代になってしまったのは残念だと思ってる
市場があれば高速化もされたんじゃないかなと

905 ：ナイコンさん：2021/06/16(水) 19:08:01.23 .net

キーボードはゲームデバイスじゃないからあれでもいいけどな
キースキャンをサブCPUに担当させない88のほうが悪い設計だと思うわ

906 ：ナイコンさん：2021/06/16(水) 19:27:12.83 .net

Z800くやしく。
実物どころかCPUボードの製作記事さえ見たことないんよouz

907 ：ナイコンさん：2021/06/16(水) 20:34:22.43 .net

Zilog - The Next Frontier - Z800 and Z80000, 1985
https://www.youtube.com/watch?v=FACRFrl_9zE
絵夢絶党の解説記事
http://mzisland.com/club/z800_1/index.html

908 ：701：2021/06/16(水) 20:39:55.19 .net

>>904
6502はデータが多いだけではない大きく複雑なプログラムを作る、走らせるには不向きだったんだと思う。
大きい分等については結局8bit系は皆使いにくくなるのだけどね

個人的には6809はCMOS化して使われる時期も遅く、クロックも遅い
トランジスタも少なくないので、16bitCPUに対する優位性が低いので使われなくなったのでは
サッサと16bit化した後継でも出してればまた違ったか？
65C816と同様に駄目だったかもしれんが。
まあ16bitは68000が有ったから敢えて6809の16bit後継は要らんと見てたかね？

>>905
キーボードをサブCPU担当にしても、柔軟な認識処理が出来ないとFM7等と同様になる
サブCPUで言えば88はFDDで読みながらゲームや音楽が止まらないとか出来たコチラのほうがデカいね。
ソフトによっては読み出し時に簡単な圧縮データの展開もしてたらしいし。

909 ：ナイコンさん：2021/06/16(水) 20:45:31.93 .net

>>906
Wikipedia によると Z800, Z280 は商業的には不成功であんまり出回らなかったらしいから現物や製作記事はないみたい

910 ：ナイコンさん：2021/06/16(水) 21:04:04.36 .net

米国製のz80なパソコンといえばTRS-80。北新宿のシャーロム教会の1Fが
タンディ新宿店でデモ機触ったことがある。残念なのはモノクロ表示。あと
基板がベーク基板でガラエポでも神エポでもなかった。安物のオーディオアンプ並み。
80年前後。タンディのオーディオ製品とかの製造拠点は日本にもあったから(二子玉TC電子)
案外日本製だったかもね。知人のアメリカ人の翻訳家が子供の頃TRS-80買ってもらって
使っていたが、ゴミカスの類。仲間内でもtrash-80って呼んでいた。と自嘲していた。

TRS-80の名を冠したcolor computer(coco)はCPUが6809。バイナリ互換じゃないよなあ
守備一貫性の欠如がTRSを終わらせたのかもね。

911 ：ナイコンさん：2021/06/16(水) 21:06:05.40 .net

守備　首尾

912 ：ナイコンさん：2021/06/16(水) 21:16:04.78 .net

神エポ

913 ：ナイコンさん：2021/06/17(木) 05:15:32.90 .net

>>908
6809と68000は同時発表なんだから6809後継16bit CPUなんか作るわけないだろ

914 ：ナイコンさん：2021/06/17(木) 13:56:03.46 .net

6502に合わせてデータ配置やアルゴリズムを変えないとならないから確かに面倒
APPLEやPETで実力は証明済みだけど使いたくないって人は多い

915 ：ナイコンさん：2021/06/17(木) 14:59:54.18 .net

コモドール64くらいに8bitパソコン後期にはC言語開発中心でアマチュアがアセンブラで苦労する事は無くなってたけどな
だからこそ1番売れた単一パソコンだとかIBM PCよりも売れ続けてたとかに成れてたのだろう

916 ：ナイコンさん：2021/06/17(木) 15:00:52.82 .net

また隔離スレから出できたのか、8bitCPUでC言語は普通に使えた君。

917 ：ナイコンさん：2021/06/17(木) 16:27:28.21 .net

どうしても6502はC言語が得意だったと言いたいらしい。

918 ：ナイコンさん：2021/06/17(木) 16:41:30.50 .net

アマチュアがアセンブラで楽々ゲーム作りまくれたから売れまくってただけ

919 ：ナイコンさん：2021/06/17(木) 17:25:32.89 .net

>>902
アクションゲーム等では使い難かったかも知れないが他の用途では癖があると感じる程度。
VRAMアクセスについてはMMUを搭載するとコストアップするのでFM-8・FM-7の当時は仕方ない。
むしろVRAM専用MPUを搭載して画期的な価格は評価すべき。

920 ：ナイコンさん：2021/06/17(木) 17:27:09.48 .net

701の人の認識だとテキストしか扱わずリアルタイムの性能なんか求められずC言語で組んでも済むような業務用ソフトの方が”複雑なプログラム”で
ゲームみたいな子供向けのくだらないものは小規模で”単純なプログラム”という認識なんだろうか

事実としてはまるで逆だよね

921 ：ナイコンさん：2021/06/17(木) 17:36:37.49 .net

GUI-OSやリアルタイムゲームなどは小さく単純だから6502向き
大きく複雑なプログラム向きなCPUではGUI-OSなど作られないって事

922 ：ナイコンさん：2021/06/17(木) 17:42:11.18 .net

もうアセンブラ書けない奴は書き込み禁止な。
何言ってるかさっぱり分からん。妄想はいいかげんにしろ。

923 ：ナイコンさん：2021/06/17(木) 18:13:03.93 .net

銀色のシール貼られちゃった

924 ：ナイコンさん：2021/06/17(木) 18:28:42.84 .net

リアルキチガイかよ。

925 ：ナイコンさん：2021/06/17(木) 18:28:57.47 .net

6800や6809のようなインデクスの使い方をすると6502はまさにゴミCPU
まぁ6800もゴミに近いからMB8861はADXが追加されMC6801ではABXが追加されたわけだが

926 ：ナイコンさん：2021/06/17(木) 18:49:53.14 .net

6502は書きにくい、読みにくい、RISC的、低級言語的、保守性が悪い。
その代わりチップが激安で値段の割には速く動く。本体が安くできる。
だからコードを「書く」側に苦労が集約されてる。
ゲーム機や、価格破壊が主眼のPC、アプリ再生機的な消耗品PCには向いてる。

だけどユーザーがプログラミング自体を楽しむ・勉強するためのPCとしてみるとこの逆の性質が欲しい。
本体価格が数万円上がったとしても長く使うのだから
書きやすい、読みやすい、CISC的、高級言語的、保守性が高いコードを書きたい。
〜5万円までの激安PCなら6502、〜11万円までの低価格帯PCならZ80でもいいけど
12〜30万円代のフルスペックPCでCPUが6502やZ80では貧乏くじ引いたような気分。

927 ：ナイコンさん：2021/06/17(木) 18:55:09.90 .net

時代設定は何時で当たりくじは何なんだよ

928 ：ナイコンさん：2021/06/17(木) 19:52:46.62 .net

6502だと
1976 KIM-1 apple-1
1978 PET-2001, Apple][ STD、
1980 Apple][ plus, CBM-4016/32, ATARI400/800
1982 Apple][ +disk][, VIC-1001/20, BBC Micro
1984 Apple///, Apple//c //e , ATARI 800XL, c64, NES

それぞれ時代相応の売価だったですな。70年台は10-30万円。
10万以下に落ちたのは82年以降。

929 ：ナイコンさん：2021/06/17(木) 20:08:18.51 .net

ESDは激高だったな。

930 ：701：2021/06/17(木) 20:57:16.96 .net

>>920
当時のゲームでは今と違って物理演算とか3D演算とかしないで整数演算だけで済まそうとするものだからな
業務用のソフトってのも表計算とかワープロくらいしか考えてないのじゃないか？

931 ：ナイコンさん：2021/06/17(木) 22:00:53.47 .net

高品質の性質が違う
ゲームはいかに超絶技巧を尽くしたところで動くモノの座標計算が狂っても面白ければかまわない
フリーズするほどの大バグが出てもバグ技として面白がられる程度
１つのゲームのプログラムは閉ざされた世界として全体掌握できる
一回完成して発売したらコードを読み直す必要はない

実用ソフトは些細な計算ミスをしても許されないしバグが出てもいけない
自分が作ったのではないモジュールを入れ替えて使われながらも
多くの環境で堅牢に動かなきゃいけない
１つのソフトを繰り返しバージョンを上げていくので可読性大事

932 ：ナイコンさん：2021/06/18(金) 01:11:33.70 .net

で当たりくじは何なんだよ

933 ：ナイコンさん：2021/06/18(金) 09:01:01.05 .net

6809よりも8088の方が良くて6809の出番が無いって事になるな

934 ：ナイコンさん：2021/06/18(金) 09:43:38.53 .net

>>920, >>931
同一人物かどうかは知らんけどゲームソフトを舐めすぎ

935 ：ナイコンさん：2021/06/18(金) 11:08:28.09 .net

920は逆だよねってのが言いたいのでは

936 ：ナイコンさん：2021/06/19(土) 06:19:59.27 .net

業務アプリもピンキリ、ゲームソフトもピンキリ。
しかし、ファミコンの多くのSLG見ればわかるとおりメニュー表示すら遅いレベル。

なぜ6502はメニューやデータの表示に苦労するのか。
スプライトのキャラは縦横無尽に高速に動くのに、ただのテキスト、キャラクタの表示にだ。

937 ：ナイコンさん：2021/06/19(土) 06:47:01.37 .net

なんでPCエンジンでは問題ないのに6502のせいだと思い込んでんだ？

938 ：ナイコンさん：2021/06/19(土) 07:16:32.73 .net

むしろPCエンジンはハード支援てんこ盛りという事実を知ってるのに
なぜそれを6502単体の性能だと思い込めるんだ？

939 ：ナイコンさん：2021/06/19(土) 07:44:13.25 .net

ハード支援ではない、テキストなどのを問題視してるからだな

940 ：ナイコンさん：2021/06/19(土) 08:32:56.11 .net

で、なぜ遅かったん？

941 ：ナイコンさん：2021/06/19(土) 09:17:15.65 .net

ファミコンならメモリ不足でだろう
RAMが2KBしかないから、ROM上の文字データを画面上で連結しながらテキスト表示する羽目になる

942 ：ナイコンさん：2021/06/19(土) 09:25:50.14 .net

今のゲームの速度感覚で早い遅い言われてもなあw

943 ：ナイコンさん：2021/06/19(土) 10:36:02.12 .net

そもそもメニュー表示が遅いとか思った記憶がない
会話の部分はあえて遅く表示してるんだろうし

944 ：ナイコンさん：2021/06/19(土) 10:45:13.67 .net

VRAMが6502にマップされてないからだよ。

945 ：ナイコンさん：2021/06/19(土) 10:45:43.51 .net

>>942
確かに、その通り。尤も今のゲームの速度感覚と言うより今のPCの速度感覚だけど。

当時でもFM-8は表示も遅かったしFM-7でも漢字表示では遅かった。因みにOS/2（1990年頃）
も「window」のドラッグ操作等では遅かった。OS支援（OS支援なら尚更）でないにしても
「window」操作が伴うなら遅くなることは当時は仕方ない。尚、PC-98（286かも知れんが）
のLIST表示（「window」操作がないので）の速さには驚いた。

946 ：ナイコンさん：2021/06/19(土) 10:51:13.43 .net

今のゲームの速度感覚でもスーパーマリオもゼビウスもグラディウスも遅くない。
時代が違うからとは言い訳としては稚拙。

947 ：ナイコンさん：2021/06/19(土) 11:16:25.37 .net

>>936はファミコンの画面表示チップがBG画面の書き換えが遅い仕様だからでCPUは全く関係ない
しかしこんなスレにいてそれを知らないはずがない。からかって遊んでるんだろう

>>943
いや遅いは遅いよファミコンのテキスト表示は滅茶苦茶に遅い
当時遊んでても不満を覚えるレベル

948 ：ナイコンさん：2021/06/19(土) 11:39:31.47 .net

ファミコンはスプライトの書き換えの方にはDMA有って高速化してるのにBGはVBlank中にCPUで書き換えろって不親切なの差が酷い

949 ：ナイコンさん：2021/06/19(土) 11:42:52.01 .net

ハード支援ないと6502はゴミ

950 ：ナイコンさん：2021/06/19(土) 11:57:40.19 .net

ハード支援どころか、ハードの都合でCPUの足引っ張ってるからの遅さなので、それで6502の速度だと思うのは違うよ

951 ：ナイコンさん：2021/06/19(土) 12:02:58.69 .net

続ファミコンプログラムを組んでみた！ - YouTube
https://www.youtube.com/watch?v=gBBLee8fLUE

952 ：ナイコンさん：2021/06/19(土) 12:09:36.12 .net

真実は>>950の言うとおりで、どうして>>949みたいなでたらめを書くやつが出るのか分からない
無知な知ったかぶりなのか、分かっててわざと嘘をついて遊んでるのか

953 ：ナイコンさん：2021/06/19(土) 12:16:53.51 .net

あいかわらず6502信者はほんと嘘ばかりだな。

ハード支援なしてBG画面がスムーススクロールできるわけがない。
BG画面でてんこ盛りハードサポートを享受しておきながら何がハードが足を引っ張ってるだ。
スプライトなんてまんまハード実装だ。

954 ：ナイコンさん：2021/06/19(土) 12:21:04.58 .net

スクロールの話とは違うんだが

955 ：ナイコンさん：2021/06/19(土) 12:24:05.55 .net

何が悲しゅうて、任意のメモリアクセスするためにゼロページにアドレスを設定しなきゃならんのだ。
その任意のアドレスは任意のアドレスに保持してたらどうやって引っ張ってくるんだ。
動的に何かしようとすると嫌がらせ無限ループになるのが6502。
すべてが静的でないとしょぼいスタックを食い尽くして立ち行かなくなるのが6502。

956 ：ナイコンさん：2021/06/19(土) 12:31:08.92 .net

ゼロページがレジスタなデザインだからだな
レジスタにアドレス設定するのに文句言ってるような話になる
TMS9900/TMS9995のように全レジスタがメモリではなくアキュームレータが専用レジスタなのは妥協してるが

957 ：ナイコンさん：2021/06/19(土) 12:31:12.33 .net

>>954
もう少し勉強してからレスしたほうがいい。まるで馬鹿みたいだ。

958 ：ナイコンさん：2021/06/19(土) 12:31:54.52 .net

スムーススクロールといえばDECのVT100がデファクト。
8080ベース。リアシーグラーのADM-3Aは純TTL構成。
スムース非対応だったような

959 ：ナイコンさん：2021/06/19(土) 12:35:36.05 .net

>>955
当時の環境では全てスタティックでもあんまり困らなくないか?

960 ：ナイコンさん：2021/06/19(土) 12:35:38.43 .net

>>957
メニュー表示はスクロールのハード支援で行ってるって思ってたのか？
Altoのハード支援ウィンドウ操作をソフトでやってると勘違いしたのの逆バージョンか

961 ：ナイコンさん：2021/06/19(土) 12:36:31.57 .net

VRAMアクセスは元から制約が厳しい。表示のために絶えず走査される。DRAMならリフレッシュも必要。
その合間を縫ってアクセスしたり待ったりしないといけない。
CPUに直接触らせないというのも設計をシンプルにする一手法だ。

962 ：ナイコンさん：2021/06/19(土) 12:40:35.51 .net

>>960
ゼルダの伝説が分かりやすい。あえてスクロールで上から降ろしてくることにより
全体の書き換えの遅さをカバーして時間稼ぎしている。

963 ：ナイコンさん：2021/06/19(土) 13:05:01.24 .net

C言語で言えば、mallocは論外だし、
ローカル変数すらスタックの少なさで実装が面倒なのが6502。

964 ：ナイコンさん：2021/06/19(土) 13:05:14.51 .net

>>961
6800や6809や6502はクロックのHとLとでメモリアクセスを分離できる
画面表示用兼リフレッシュ用メモリアクセスとCPUメモリアクセスや、DMA用兼リフレッシュ用メモリアクセスとCPUメモリアクセスやら分離するのが定番化してた後のファミコンが分離してないのでシンプル化と言っても時期的にオカシイ
まるでZ80前提に作られてたのを後からCPUだけ6502に置き換えたかのような不自然な仕様の部分がある

965 ：ナイコンさん：2021/06/19(土) 13:09:54.49 .net

カバーしてないのはハードの都合による遅さって事で、ハードの都合な補強でしかない意見になってるが

966 ：ナイコンさん：2021/06/19(土) 13:14:07.99 .net

6502はバスをほとんど遊ばせないという点で8bitバスCPUとして理想に近い形してるよ
デコード中やアドレス読み込んでいる間何もできないバカZ80は少し見習えと

967 ：ナイコンさん：2021/06/19(土) 13:16:57.55 .net

> 定番化してた
おいおい、どのメーカー基準だよ。83年発売だぞ。

968 ：ナイコンさん：2021/06/19(土) 13:17:58.57 .net

遊ばせないために16bitレジスタを削除しました

969 ：ナイコンさん：2021/06/19(土) 13:20:04.74 .net

>>967
Appleもコモドールもやってたぞ
ファミコンはC64よりも後の遅れて来た機種だ

970 ：ナイコンさん：2021/06/19(土) 13:22:26.82 .net

プログラマを遊ばせないためにSPも8bitにしました

971 ：ナイコンさん：2021/06/19(土) 13:26:02.27 .net

黎明期にコンピュータゲーム機を開発するのにゲーム機でなく
パソコンのAppleIIだのC64だのハードを細かく解析してから設計するのが当然だというのか。

972 ：ナイコンさん：2021/06/19(土) 13:30:53.06 .net

>>961
表示のために絶えず走査されるならDRAMでもリフレッシュは不要。

973 ：ナイコンさん：2021/06/19(土) 13:33:11.23 .net

>>971
ファミコンって別に黎明期でもないな
任天堂とエポックが家庭用ゲーム専用機を出し合ってて、アメリカではアタリも盛り上がった後の、中興の祖ではないかな

974 ：ナイコンさん：2021/06/19(土) 13:34:43.60 .net

>>971
N社の宮本氏は御茶ノ水のパイナップル6502に足繁く通い
毎度ごっそり新着ソフトを買って持ち帰っていた。という話。
店長氏の奥様が常連さんとそんな内輪話をしていたですよ。

975 ：ナイコンさん：2021/06/19(土) 13:37:49.65 .net

いつものようにおじーちゃんとおっちゃんは話が数年ズレている。

976 ：ナイコンさん：2021/06/19(土) 13:44:38.24 .net

>>969
赤白ファミコンは9801の発売前。82年の晩夏の晴海エレクトロニクスショーで
実機デモしていたから。基本設計はそれ以前でしょうね

977 ：ナイコンさん：2021/06/19(土) 13:46:02.47 .net

>>958
スムーススクロール搭載してたMZ2500がどういうチップ使ってたのか知らんけど、なにをつかってたんだろう
と、スムーススクロールで思い出して疑問に思った

978 ：ナイコンさん：2021/06/19(土) 13:47:20.94 .net

>>961
今から思うと同意だけど、MSXより前には、あんまりメジャーな手法じゃなかった気がする

979 ：ナイコンさん：2021/06/19(土) 13:48:03.63 .net

リコーに6502なら音源も含めて1チップ化できるって説得されたそうだからね

980 ：ナイコンさん：2021/06/19(土) 13:51:28.86 .net

>>972
VRAMのほぼ全域が表示用にスキャンされる古いゲーム機、古いパソコンあたりならともかく、8ビット時代後半や16ビット初期パソコンの時代だと、表示対象外（複数画面もち対応とかで）のVRAMが少なくないからリフレッシュ必要だぞ

981 ：ナイコンさん：2021/06/19(土) 13:53:44.74 .net

あ、980か

挑戦してくるから、埋まらないようにしばらく書き込み停止しててほしい

982 ：ナイコンさん：2021/06/19(土) 14:05:18.60 .net

8086 vs. Z80 vs. 6809 vs. 6502　その15
https://matsuri.5ch.net/test/read.cgi/i4004/1624078918/

これで大丈夫だろうか?

前々スレにならってﾜｯﾁｮｲ有効にしたが、これでいいのかどうか不明

賛成と反対のどちらが多かったのか教えてくれ
無しにして建て直した方がいい?

983 ：ナイコンさん：2021/06/19(土) 14:10:45.23 .net

>>966
Z80は、動作タイミングの基本4サイクル分の期間のうち2サイクルがメモリアクセス期間
残りの空き時間を使ってリフレッシュなりVRAMの表示用のリード時間なり入れろってのがデフォだったような?
4サイクルより長い命令の多くはメモリアクセスを追加で行うために時間を使ってるはず
メモリアクセス無しで余分の時間使う命令なら、4サイクルじゃなく2サイクル単位で処理時間が延びてたような

984 ：ナイコンさん：2021/06/19(土) 14:16:03.18 .net

>>980
ああ、どんな画面モードでもROWアドレスが絶えず走査される古いハードのつもりだった

985 ：ナイコンさん：2021/06/19(土) 14:18:23.77 .net

>>983
4サイクルはM1サイクルだけ。前半がインストラクションフェッチ、後半がリフレッシュ。
他のメモリアクセスは3サイクル。

986 ：ナイコンさん：2021/06/19(土) 14:50:25.31 .net

>>963
mallocが何故論外なんだ？もしやスタック上に取るとでも思ってる？

987 ：ナイコンさん：2021/06/19(土) 14:54:40.82 .net

6502ならmallocは余裕君がまたやっきました。

988 ：ナイコンさん：2021/06/19(土) 15:05:39.57 .net

またとか訳の分からない誤魔化しで説明できず逃げるだけか

989 ：ナイコンさん：2021/06/19(土) 15:07:22.98 .net

6502はC言語に向いてる。mallocとか余裕で実装可能。
とキミが連呼してることはよく知ってるが隔離スレから出てくんなよ。

990 ：ナイコンさん：2021/06/19(土) 15:08:29.04 .net

6502はお利口さんには使えないCPUです

991 ：ナイコンさん：2021/06/19(土) 15:12:08.85 .net

>>989
誰と勘違いしてるのかは知らないが、自分が説明できないのを誤魔化せてないぞ

992 ：ナイコンさん：2021/06/19(土) 15:16:44.06 .net

> mallocが何故論外なんだ？もしやスタック上に取るとでも思ってる？

mallocに食いついてなぜかスタックの話する時点でかなりレベルが低いというか
左翼みたいに自分では説明せずすべて質問形式で知ったかしようとしてるのがバレバレです。

993 ：ナイコンさん：2021/06/19(土) 15:20:04.32 .net

>>992
文脈を読もうな
>>963 が何故か無関係なのにスタックに繋げてるからの話だぞ

994 ：ナイコンさん：2021/06/19(土) 15:23:25.51 .net

一般的な実装ではローカル変数はスタックに積むものだが。

995 ：ナイコンさん：2021/06/19(土) 15:24:12.36 .net

この人、6502のcコンパイラなんて制限だらけなのも知らなさそう。

996 ：ナイコンさん：2021/06/19(土) 15:26:17.34 .net

>>994
mallocとローカル変数は別

997 ：ナイコンさん：2021/06/19(土) 15:33:15.39 .net

>>996
つまり同じと言ってる人は誰もいないのに、6502を馬鹿にされたのが悔しくて悔しくて発狂しすぎて、
相手がmallocとローカル変数をごっちゃに勘違いしてる馬鹿だということにして、自分を正当化したいわけだな。

隔離スレと同じ構図だな。やっぱりキミはあの痛い人だよ。8bitCPUでC言語がふつうに使える君。

998 ：ナイコンさん：2021/06/19(土) 15:39:35.68 .net

正当化も何も説明してくれってだけだったろ
説明できてないから墓穴掘ってるだけな自覚無しか

999 ：ナイコンさん：2021/06/19(土) 15:47:09.84 .net

> mallocが何故論外なんだ？もしやスタック上に取るとでも思ってる？

説明してほしいのに挑発するように質問したの？
人を見下したら説明してくれると思ったの？

低レベルの質問なら初心者スレへどうぞ、クソ野郎。>>998

1000 ：ナイコンさん：2021/06/19(土) 15:51:24.32 .net

>>999
結局説明も出来ず嘘付いてたのを誤魔化し続けるだけか

1001 ：2ch.net投稿限界：Over 1000 Thread

2ch.netからのレス数が1000に到達しました。