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

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を必要としてた