２ちゃんねる ■掲示板に戻る■ 全部 1- 最新50

■ このスレッドは過去ログ倉庫に格納されています

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

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Ⅱ」のことですか、それとも最近の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Ⅱ」に搭載した理由は>>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: 半導体を売る側から見ると、顧客のデバイス選択の優先度は
①単価
②供給能力。納期の安定性。
③開発スタッフのスキルと慣れ親しみの度合い。
④デバイスの性能。

購入者側からすれば、製品性能が最重要だろうけどね。
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に到達しました。

総レス数 1001
281 KB

掲示板に戻る全部前100 次100 最新50

read.cgi ver.24052200