ファミコンってＣ言語でプログラムされてるの？

プレステ２もＣ言語でつくれる？

ファミコンはアセンブラ

>>2
正確に言えば性能を追い求めたものはアセンブラ
適当に作られたものはＣ言語だろ

>>3
ファミコンは全部アセンブラ。

FORTHで書いた馬鹿がいた、NMI処理までFORTHだった、一辺子ねとかおもった。

ファミコン版が初めて Pascal 以外で書かれた Wizardry という
ことになるのかな？

>>5
パソコン版はみんなパスカルだったんですか…

>>6

>>4
FORTH、速度十分やし、割り込み処理でもインラインアセンブラ使えば全然問題ないのと違います？

>>8
京都人?

>>1
ttp://www.freescale.co.jp/codewarrior/products/game/ps2/index.html

初期の信長はBasicｺﾝﾊﾟｲﾗだっけか

インタプリタ自体が載ってそうな価格だったけどな

Z80 の CP/M 上に 6502 用のクロスアセンブラという環境だった。
携帯型のオシロスコープのようなマシンで、幻の 3inch フロッピー(3.5inch ではない)がついていた。

スーファミもアセンブラ？プレステ１くらいからＣ言語になったのかね。

>>4
ファミコン（6502）のNMI？

>>13
3インチは幻でも何でもないですよ

SFCの頃はソニーが誇る格安ワークステーションのNEWSを使ってたんだっけか。
c言語でもできそうだけど、SFCはCPUが貧弱だったし、ROM容量をギリギリまで使う事考えると
アセンブラで書いてたんだろうなぁ。一応、ファミコンのやつとは上位互換の石だったし。

波形メモリとドライバ含めて64KBとか、真性マゾなサウンドプログラマーは小便垂れ流すほど喜んだに違いない。

>>6
ファミコン以前はそうだね。
Wiz自体の移植というより、Pascal環境の移植が大変だった。
Pascalはコンパイルしても、今でいうJAVAとかC#みたいな中間言語
形式だし。

>>17
へええ知らなかった
久しぶりにX1版やってみるか…

じゃあ遠藤の仕事って偉大だったんだな。当時ＦＣ版wizこんなもん簡単に移植できるだろと思って馬鹿にしてた。環境含めて全部一から組みなおしたわけなのか。

ファミコンに移植したいって打診したら先方に
「ファミコンにはPascal環境無いから移植できるわけねーズラ(ﾜﾗ」
って言われたんで意地でもアセンブラだけで移植してやるとか思ったとか。
頑張ったのは認めるが、ぬるいバランスに改竄しやがってこの野郎、と言いたい。

ファミコン版Wizは羽田健太郎という名前を知るゲームだったな。
まあマクロスで既に知ってたけど。
ご冥福をお祈りします。

68000のニモニックを6502のニモニックに変換するトランスレータなんて作ってた。あの頃

一部のコーエーのファミコンゲームはC言語で作られたって聞いたことあるんだけど、どうだっけ。
C言語で作るためにカセットの容量を大幅に拡張したとも聞いた。
もしかするとSFCの記憶違いかもしれない…

光栄ってなんであんなに馬鹿高かったの？
ナムコが3900円に対して1万強だよ？

>24
過去形じゃなくて今でも高いよ

>>25
ナムコのあれの３９００円シリーズでは当時任天堂と大喧嘩してだでそ。当時の任天堂ってまだ半分ヤクザみたいなもんだったからナムコは相当びびってただろうね。結局何本か出してナムコ側が屈服したけど。
光栄みたいにぼったくりで高く出す分には任天堂はニンマリしてくれるんだよね。

>>3
6502を知らないから、そんな無知なことを発言できるんだよなぁ
きもいよｗ
あれを現状のアセンブラと比較するのは酷なもんだよ。
すくなくともアセンブラを知っているならアドレス指定が８ビットだけの
世界で何ができるか考えてみたほうがいい。
家電で使われている４ビットＣＰＵよりツカエネーぞｗ
知っていれば難解なパズルとか、機械仕掛けの精密な腕時計と比較するべき
存在だとおもわれ。
同じアセンブラでも68000のアセンブラと6502のアセンブラを比較するなら
犬の遠吠えと人間の会話ぐらい違うよ。
８ビットＣＰＵでＣ言語がツカエネーのは単にメモリ空間とレジスタ幅の
問題といったほうがいいかもな。
１６ビットＣＰＵ用でもサブセットなＣ言語と見なしたほうがいい。
６８０００は命令語レベルのアーキテクチヤ系は３２ビット仕様
Ｚ８０でぎりぎり１６ビット、８０８６でも１６ビット、８０３８６で３２ビット
６８０９もぎりぎり１６ビット、

アップル２のＶＲＡＭ仕様が６ＫＢでカラードットグラフィクスを実装できた
事実を計算して矛盾がでないか試算できるほどの能力があれば、
６５０２の時代の技術屋がどれだけ難解な職人だったか理解できるよｗ

>>20
バランスは使用言語と関係ないだろ
>>27
富豪的環境しか知らないゆとりにマジレスするなよ

PC版Wizは「不正」前提での難易度。
まあエミュ世代じゃ何のことか判らんだろうな。

アドレス指定が8ビットとか、Z80が16ビットとか、どこから沸いた妄想なんだ？
6502はちゃんとアドレスバスが16本出てるんだが。
機械語レベルでみても、絶対番地(当然16ビットだ)、インデックス付き絶対番地、
プログラムカウンタ相対、ゼロページ、インデックス付きゼロページ、と、
アドレッシングモードは十分に容易されてるし、ゼロページを8ビットまたは16ビットの
レジスタ群とみなせる分だけ強力だ。
というか、Z80ごとき非力なヘナチョコ8ビットの石では、使いやすさで6502の足下にも及ばんよ。

でも、スタックポインタは8bit

ARMはどう？

ARMは変態

ARMとか寄り道してると人生損した気分になるよな

あるあるある

条件ジャンプならぬ条件比較が好きで今も忘れられないんだけどな…

C言語でもなんでもいいけど、
それはどこが作った処理系なの？

>>30
そんな意味の強力さでは、スレタイトルのＣ言語ネタになっていないだろ。
マヌケ君か？
Ｃコンパイラの仕様を満たせる6502のＣ言語があるのか？

>>38
ANSI準拠なクロスコンパイラなら既にあるから、Cを使った6502開発は可能だが？

>>39
トンデモがきたか？
自作で行うのと。商品で行うのは別だよな。
Ｃは6502レベルだと高級すぎてハードウエア的に無駄の塊になる。
つまり6502のバイナリ−レベルには最適化できねーんだよ。

何この電波だらけｗ

>>39
デンパ君かえれ

>>38
>マヌケ君か？
>>27 ほどじゃないと思う。

チキンレースかよ…

>>40
無駄が生じるのは承知しているが、組み込み分野ではC言語を使うという選択肢が
現実に存在している。ほれ、この通り。
ttp://www.iar.com/index.php?show=1140_JAP&&page_anchor=http://www.iar.com/p1140/p1140_jap.php

Cコンパイラの仕様を満たせる6502のC言語があるのか、と問われたから、
実在すると答えたまでだ。6502、Z80、6809みたいな8bit CPUをターゲットに
C言語を使うとき、バイナリレベルの最適化を目的にするアホはいない。

そもそも、c言語に向いてないという意味ではZ80も同じ。
なぜ6502だけが向いていないかのように誘導するのか不思議でならない。

http://c-au.2ch.net/test/-/mass/1183191945/i#b
http://c-au.2ch.net/test/-/soc/1152718893/i

>>45
シビアな用途では向かないのは当然だろう、おまえはＲＯＭとＲＡＭの
容量計算もできないのか？

>>47
計算できるかどうかと、Cコンパイラが実在するという事実の指摘に
一体何の関係があるのやら。
あんた一体何がしたいんだ？

ROM化の話となれば、現行の高級なCPUでもＣ言語使うには制約多いってのｗ

>>49
どんな制約?

RISCの命令セットはCに向いてるとは言えない。

夏真っ盛り

>>52
うん。無駄に熱い (≠暑い) ね。

インターネットの噂に依るとPSはBrainfuckで作られたそうです。

Appleの頃の6502ユーザーとFC以降のユーザーが
時空を超えて議論してるの？
”当時”の意味がそれぞれ違う気がするが・・・

>>55
PET2001ユーザとPCエンジンユーザかも知れず。

まあ、脳みそが硬化してる耄碌ジジイはすっ込んでてもらいたいね。
自分が言いたいことをわめくばっかりで、全然人の話を理解してない。

Cは、PDP11とかのCPUに親和的に出来ているんだよ。
ミニコンから派生したM68000とかにも親和的。
そのCPUのインストラクションセット知ってると、
なぜインクリメントを++と書くのか、分かるよ。

>>58
>なぜインクリメントを++と書くのか、分かるよ。
インストラクションセット知ってるけど、わからない。なぜ？

68000だと、
mov.l (a0++),D0

とかあったよね？

PDP11なんてシランけど。

>>58
＞なぜインクリメントを++と書くのか、分かるよ
むしろそれ以外に何か書きようあるか?

>>61
inc x
up x
x<:1

>>61
むしろ何故そんなものを導入したのか、疑問にも思わないのか？

>>58
The Art of UNIX Programing によると、インクリメント演算子がPDP11から来てるってのは都市伝説らしい。

PDP7 向けの B 言語の時に既に ++ はあったんだっけ?

>>62
微妙だね･･･

>>63
良く使わない?

マクロ展開したりすると副作用があるんだよねぇ++って
言語体系としてはいまいち使うの注意って感じだよ。

move.l d0-d7/a0-a5,-(sp)
move.l (sp)+, d0-d7/a0-a5
↑こういうのは知ってるが

mov.l (a0++),d0
↑こんなのは知らん。

む、いかん。moveではなくmovemだった。

>>48
単なる粘着ヴぁか？、何も知らないって愚かだよな

>>70
よう、おかえり。

漢が熱い萌える闘魂プログラマーだから

技術があるのも知識があるのも素直に尊敬するけど、
それが曲がった人間性を補強する材料になってしまうのは
ちょっとなぁと思う20代

>>71
自作自演はいい加減やめとけ、消防レベルだぞ

>>73
技術や知識があるから曲がった人間になってしまうというのもあるよ。
周りの人間に足引っ張られてばかりだとね…

>>30や>>45あたりは、まともなこと言ってるようにしか見えないのって気のせい？
調べてみたら>>27に書いてあることって、本当に嘘だらけだったし。

>>73
まっすぐすぎるのも面白くないもんだよ

爺さん同士の馴れ合いはマ板でやればいいのに・・・

いいのに？

>>74
妄想癖ではないとしたら、相当間抜け。

>>76
ただ >>31 みたいな事情もあるんで結構使い辛い。
安いだけのことはあるっつーか。

ゼロページレジスタという最強の武器をもってこのザマか。

まあ、それでもZ80使うよりは楽なんだけどね。
家庭用だとMSXとかがZ80使ってたけど、あれのCコンパイラは酷いもんだった。

LSI-C80はそれなりだったよ。MSXとじゃ、時代が違うけど。

>>80
アセンブラもしらないのに何でオマエが書き込みするんだ？

LSICの存在価値はプレインテキストの関数リファレンスだけだったな。

>>39
遊びと仕事を区別できない奴だなぁｗ
6502でクロス使ってもメモリに入りきらなければ意味ねぇじゃんｗ

> 6502でクロス使っても
クロスコンパイラの意味わかってる？

わかってないのは>>87の方だったりしてｗ

>>88
分からないから説明して

クロスコンパイラでは、実メモリ以上のサイズの実行コードをいくらでも吐き出すのさ。
64KBしかアドレス領域の無いマシンに100KBとかの実行コード乗せられねえだろ。

クロスコンパイラでは、実メモリ以上のサイズの実行コードをいくらでも吐き出すのさ。
32KBしかROM領域の無いマシンに40KBとかの実行コード乗せられねえだろ。物理的に

>>90の書き込みはさすがにウソだ、忘れてくれｗ

でも元の話はANSI C対応のコンパイラが存在するかどうかという話だったのだから、
実用性は二の次以下にしか考えられていなかったと思う。

>>91はクロスコンパイラの説明にまったくなってないんだが
クロスコンパイラの 「 ク ロ ス 」 の説明をしてくれないか

布

つまんねーヤツｗ

なんか仮定の想像の域のエセ論理と、リアルの話が混在している。

理屈だけ先行しても現実に使えないものは使えないでＦＡじゃないか？
ときどきいるんだよな、理論と現実が合わないと理論で行動して事故に
合うマヌケ君てｗ

お前 ｗ ←これ好きだなぁ
あと意味のわからない単語を知ったかぶりするのは止めた方がいいよ

クロスコンパイラって、パソコン上で6502のマシン語コードを吐き出す奴。

それだけがクロスコンパイラかいw

>>99
Apple][やPET2001もパソコンだけどそれらが6502のコード吐いてもクロスコンパイラなの？
コンパイラの存在は別として

ああ、Z80のマシンで8086のコードを吐き出しても、クロスコンパイラ

ホストＣＰＵと異なるＣＰＵ向けの実行コードを吐き出す奴は、全部クロスコンパイラだぁ
もんくあっか？

ならx86 Linux上でx86 Windows用バイナリを吐き出すGCCは何？
俺はこういうのもクロスコンパイラの内だと思うんだけど。

それで合ってるよ

>>100
「それ」以外の説明をおながいしますｗ
ぜひｗｗｗ

もしかして>>102はApple][やPET2001がZ80だと思ってんのか？

>>107
んなわけねえだろw

このスレってファミコン全盛期当時の環境前提での話だよね？

＞6502のレジスタはPCが16ビットであることを除き、すべて8ビットである。
って書いてあるんだがファミコンは８ビットでおｋ？

昔から思ってたんだけど
Apple][
って表記はきもいです

そんな文句はアップルに言ってくれ。
起動画面に APPLE][ と出してたのはアップルなんだから。

6502でコードがどのようになるかすら知らない無能君がクロスコンパイラとか
Ｃ言語とか抜かしているのが笑える。
そもそもアセンブラのニーモニックの一部をみたことがある程度じゃないのか？
6502でＣのソースを機械語へ翻訳するのは可能だが68000なCPUと比べれば
そのコードが桁違いに増大するのは明白だろう。
そもそもビット数がないレジスタとメモリ空間が６４ＫＢしかない
極小の世界というのが理解すらできていない。
何をするにも８ビットの壁が存在するのが6502だろｗ
8086で16ビットの壁があって80386で32ビットの壁がある、これは明白であって
それ以上のことを模擬したとしてもそれは模擬でしかすぎない。
数百倍も手間がかかるクロスコンパイラが吐き出すコードなどに意味がある
訳が無いだろ。８ビットでこそ効率的に処理できるＣＰＵに３２ビットで
表現するのが普通なＣ言語というのは無茶すぎる。
8086のＣだって無理があり制限機能だらけだった事実すらしらねーのが
クロスコンパイラが存在するから可能だと言うのはロケットがあるから
シリウスまで飛べるはずだと誇張するようなものだろｗ
妄想もいい加減にしておけ。無知は困るよな。
いまのＣＰＵの概念すら通じないＣＰＵだってあるんだぞ、
具体的に条件分岐命令が存在しないＣＰＵとかだｗＮＥＣ製にあるｗ
古いＣＰＵについて無知なのは当然だろうけど、思い込みもいい加減にしておけ。

そんな長文（しかも的外れ）書くほど悔しかったのか？

どうでもいいけど4bit=1nibble

じゃ16オクテット=1パラグラフ

まあ、まあ、８ビットCPUでも十分短い実行コードで十分実用可能なんだけどね。
特に6502とか、6809の系統は、メモリーへのアドレッシングが豊富だから。
あと、6502は、零ページレジスタと言って簡単に扱えるメモリー領域があるから、
ちょっとしたコードならすごく短く済む。

遅延ジャンプ搭載！

リロケータブルジャンプとか懐かしいな。

>>118
x64で再配置可能なプログラムが画期的な新機能のようにアピールされている件

お前らオペランドジャンプって分かる？

>>112
>３２ビットで
>表現するのが普通なＣ言語
↓
>無知は困るよな。

>8086のＣだって無理があり制限機能だらけだった事実
kwsk

>>121
6502で１ＭＢのメモリをコピーしてください。ｗ

>>122
先ずは、1MBのメモリをコピーできる、6502搭載のシステムを用意してください。
その仕様を明らかにしていただければ、必ずやコピーしてご覧に入れましょう。

>>122
6502で1MBのメモリコピーになんの実用性も有るとは思えんが・・・
お前はバンク切り替え知らんのか？

知らんのか？

Z80のバンク切り換えで実現した仮想ディスクを思い出した。
バンク切り換え8ビット+アドレスバス15ビットでやっと8MB……

>>124
おまｗなんの実用性も無いものを、

クロスコンパイラがバンク切り替えのコードを自動で吐き出すのか？ｗ
わざわざ無意味なことをｗｗｗｗｗ
6502にＣ言語なんて笑えてハライタイｗ

Ｃ言語でプログラムされるか？というスレッドで、Ｃ言語プログラムが
まともにできると粘着して主張している奴がいるｗｗｗｗ

ありえねーーーｗｗｗｗｗｗｗｗｗｗっうぇえうぇっうぇえっうぇえｗｗｗｗ

＞バンク切り替え
つかバンク切り替えのハードウエア追加してどうするｗ
それじゃ６５０２のＣＰＵ以外の機能で実現するシステムじゃんｗ
ＦＰＧＡで組んだＣＰＵに実装でもするか（ｒｙ

つＤＭＡＣ

> ありえねーーーｗｗｗｗｗｗｗｗｗｗっうぇえうぇっうぇえっうぇえｗｗｗｗ

C言語は初期UNIXを移植するために作られたわけだが、
そのターゲットはDEC PDP-11
PDP-11 は16bit CPUで、その仮想アドレス空間は64k

ちなみにC言語はB言語を参考にしている

B言語はA言語を

↑嘘吐くなｗ

B言語はBCPLのサブセットじゃなかったっけ？よーらんけど。

パソコンに繋がった自律ロボットにプログラムを転送する場合も
パソコンでロボット制御を制御していることになるのか？

6502のＣＰＵならそれ自身でＣ言語でプログラムグ環境と実行環境と
実際に開発できた市販アプリが１件でも存在しているなら
6502のＣ言語でプログラムされたという事実を認めてやろうｗ
嘘はくなよな

D言語はDelphiを

>>27 は、その情熱を仕事に向けるべきだと思う。

>>18
パッケージや取説にかいてあったろ？

どうして　>>86みたいゴミくずが放置されているの？

6809でｃ使ってアプリ書いたことあるよ。

FM-77ですけど。

＞嘘はくなよな
「嘘吐く」と書いて「うそはく」と読む人ですか?

出発（でっぱつ）

>>142
それは嘘を「はく」でいいんだよ
日本語として何もおかしくない。
恥ずかしい奴だなおいw

>>134
まぁBCPLやPascalといった手続き言語は ALGOL の影響を強く受けてるから
間違いじゃないよな

>>144
菊は一時の恥と申しまして。

この人には何言っても無駄だよ

嘘吐くを「嘘はく」と読む「嘘はき」がいるスレはここですか？

ほぼ全てのスレに居ると思うが…

この吐くに関しては、表外音訓だから、
普通の文章では、漢字であんまり書かないし、
間違う人はいる気がする。

嘘じゃなくて、悪態とかだったら、読みを考えただろうけど。

間違うも何も「はく」も「つく」も両方間違いではないんじゃないか？
うそをはくって言い回しはちょっとレトロな感じだね

>>112
どんなに長文を書こうとも、実行速度は6502>68000。
PCエンジンとメガドライブをみればその実力差は明白。

念のため任天堂ファミコンはRICOHカスタムの65C02だったよな。

HuC6280は確かに、メモリも組み込まれてて速かったな。

１ＭＨｚで動作するＣＰＵでＣ言語を語るスレですか？
ＧＨｚの時代にＣ言語が１ＭＨｚなんて、日本海の水をコップで
太平洋にくみ出して水を増やしているような次元だろ。
あたま悪すぎｗ
そもそもポインタが８ビットアドレス以外つかえなようなＣＰＵで
何ができるんだ？２５６バイトの最大配列か？

>>155
>そもそもポインタが８ビットアドレス以外つかえなようなＣＰＵで
帰れ莫迦。

>>155
機体の性能でゲームの面白さを語れると思ったら大間違いだぞ房や。
昔の人はそれでも頑張った。

シャアかw

FFXIよりも初代スーパーマリオの方が面白いのは間違いない

昔のゲームって
いい具合に抽象化されてるから、感情移入がしやすいんだよね。
だから面白いと感じるんだよ。

感情移入してた奴なんかむしろおらんやろw
マリオやアーサー（魔界村）やビッグバイパーに感情移入してる奴がいたら怖いわ
何をいってんだチミは。

ここは加齢臭が目にしみるスレですね

>>155
言ってる事がよくわからない。
6502のインデクスレジスタは8bit幅だが、0ページの連続した2バイトをアドレスレジスタとして
使えるから、ポインタそのものは16bit幅になるんだが。

まさか、Z80は8bit定数しかディスプレイスメント値として指定できないから、
Z80ではポインタは8bitアドレスしか使えない、などと間抜けた事は言うまい？

>>163
１６ビット幅でも足りないよ、ゴミ以下

とりあえず光栄は何らかのコンパイラ使ってたかも。
遅い上にワーク用のRAM増やしてたし。

ANSI-Cは1989策定だから当時は使われていないか、
存在していなかったと思う。

>>164
16bitのアドレスバス幅しかないのに足りないってどういうこと？ｗ

ファミコンでCで組んでた実例とか示せば一発なのに、なんでしないの？

デザイナーなかじまかおる

>>166
逆に質問するが、どうやって実例を示すんだ?
ゲーム会社は自社の技術の流出を防ぎたいから、
「当社ではファミコンソフトの開発にCを使ってます(使ってました)」
と公式に発表した記録なんてないだろうし、
「俺は昔、Cでファミコンソフト作ってた」
「これが、ゲームソフト○○のソースコード」
みたいな書き込みは真偽の確かめようがない。

ｃ使ってファミコン開発してた初老のじじいがほくそ笑むことの出来る瞬間。

>>166
ファミコンはしらんけど、6502のapple IIはふつーに各種コンパイラが動いてただろ。

80年前後にそんな気の利いたものがあるわけなかろうがw

>171
少しぐらい調べろや

>>170
AppleII用はTinyベースで動いていたね。
しらねーのか？
それらはモドキであって、それ以上ではない。実際に物も使ったことないんだろ？
>>172
調べる？アフォかよ。本体もってリアルでやっていた人に物を言う
姿勢か？ｗ
昔話しても仕方がネェけど。おまいらが想像する世界を越えていたのが
AppleIIだろ。
あのハードウエアでとてつもないソフトや性能や技術を満載していた原点に
もあたる存在でappleが神であった証がappleの初期マシンにある。

>>173
最初から最後まで全く意味がわからんレスも珍しい
そもそも何が言いたいんだ？

>173
>172 は >170 の発言を肯定しているじゃないか

だからつっかかってるんでしょw

80年前後にもマイコン用のコンパイラはそりゃああるにはあったけど、
オモチャであって実用レベルの代物では到底なかったと思ったけど違ったかな？

UCSD Pascal が Apple][ で動いてたような気がするが。

>>176
元々今のPCに較べれば玩具にも劣る性能しかないPCで、今の基準で実用的なものが作れるわけがないっしょ。
それとも何か? ENIACは玩具だったとでも?

今の基準ったって絵や文字が細かく表現豊かになっただけで、
必要最小限の能力は十分あっただろ。

ま、今ですら画面ひとつの情報量は証明写真くらいの量しか無いけどな。

性能からいえばENIACよりApple][の方がマシではないかな
それにENIACは動いているより修理している時間の方が長かったしな

>>178
まあいいから落ち着いて「話の文脈」を確認し給えよ。
短絡的に人の言葉尻を捕らえてないで。

>>170が当時フツーにコンパイラが使えるし使われている状態だった、
といっているからそれは事実誤認だといっているに過ぎんだろう。

>>181
だから、Apple][ではUCSD Pascalが普通に動いてたって話じゃん。
少なくともそれで弾道計算くらいは充分できていたよ。

80年頃にAppleII使って弾道計算するのが「ふつー」の使い方かw
こういう自分の間違いを認められない可哀想な奴と話してると疲れるな

「弾道計算くらいは充分できていた」≠「弾道計算するのがふつー」

>>184
そういう自分の勘違いを認められない可哀想な奴と話してると疲れるな

Apple][で弾道計算していたなんて誰も書いてないけどな
それはそれとして弾道計算するのにPascalコンパイラは必要ないんｼﾞｬﾏｲｶ

>>185
日本語読めないならもう来なけりゃいいと思うのね。

なんか弾道計算は世界最初のコンピュータ時点で扱われていた問題で
6502で「ふつー」とか言っている時点で意味不明な発言なんだか。ｗ

>UCSD Pascal
>>182
おまUCSD Pascalを知っていもしないのに何をはびょっているんだ？ｗ
仮想マシンのPコードが動けばどのマシンで動くといわれている奴で
リアルに動いているようなものじゃないぞ。
そもそもＣ言語がPコードで動くなんて始めて聞いたが
Ｃ言語の話をPascalに脳内捏造でもしたのか？

6502で動いてたんなら、p-codeでなにが問題かわからんけど。

論点は、6502とCで実用的なものが作れるかってことだろ?
信長の野望とか大戦略の初期のやつはZ80でBASICだし、6502とCの組み合わせでも
余裕で組めるね > 商用レベルのゲーム

実用の意味がわからん
まるで当時のパソコンでは実用ソフトが皆無だったような書き方は好かん。

組込みレベルの開発でもCは実用的な物を作れる。
というか使われてる。

>>191
>組込みレベルの開発でもCは実用的な物を作れる。
>というか使われてる。
たしかに間違いではないが、激しい誇張で嘘の域に近い。
実態はマクロとインラインアセンブラだらけだろ。
経験もしたことが無いことを語られてもなぁｗ

>>192
自分の居る井戸の狭さに気付いた方が宜しいかと。

安易に「組み込み」なんていう振り幅のひろい言葉を使うのはどうかとは思うが、
191の言ってることの方が正しいね。

8051ですらC（もちろん特殊仕様ではあるが）が普通だし、H8ならC++が使えるしね。

組み込み Linux みたいなのも組み込みだからなあ

H8ぐらいなら、一部アセンブラでほとんどCでかけるだろ。

さらしアゲｗ

なんか面白い話してるね。
当時 Apple ][ で確かに幾つかの言語のコンパイラはふつーにあった。
でも、それで実用アプリ？（表計算にワープロにゲームとかかな）を
作っているかどうかとなると、、、Wizardry が PASCAL だっけ？
まぁ、あったんじゃないかなとは思う。

で、ファミコンで C だけど、Apple ][ のアセンブラと C を使って
プログラム作って、それをファミコンのカセットに焼いて動かす
ということは実際に自分もしていたよ。

組み込みでもC++を使いたい

ならばColdfireを推進したまえ。

C++って、クラスメンバーへのインデックスが静的に決定されるから嫌い。
何かあるごとに毎回全コンパイルなんて、やってられん。

なんのこっちゃw

>>201
はぁ?

>>201
つpimpl

>>198
嘘もほどほどにしろよ、どこのメーカーのＣ言語だ。ｗ

Ｃコンパイラも自作できないとは

Cインプリタなら作れます

Forthが動けばいい

>>205
Aztec-Cは無かったことになりましたか？

まとめに入るか。

ファミコンゲームがアセンブラで作られてようが
CとC++使ってもファミコンゲームみたいなんは楽勝だろ？

だったら、今の時代に合わせて
C言語でやれや。

以上。

ーーーーーーーーーーーーーーーーーーーーーーーー終了ーーーーーーーーーーーーーーーーーーーーーーーーーー

論点から滅茶苦茶離れたことをいきなりまとめとか言い出すキチガイはいったいなんなんだろうな。

>>27 でキチガイが登場して以降は、本筋ではありません。

今の時代に合わせてCだなんて
そんな不味い餌にこの俺様が熊熊

なんでファミコンでＣ言語なんて（ｒｙ
これはファミコンでエクセルやワードが動くというのと同等だろｗ
ファミコンでイルカの代わりにマリオでも動かせよｗ

全然違いますな。ファミコンでCコンパイラは動くけどエクセルは動かない。

＞ファミコンでCコンパイラは動くけど
それ本当かw

ファミコン程度の構成でも動くことは動くな。

頑張って、ファミベでCコンパイラを作る。

>>216
先天的な嘘付きに触ると後でＤＱＮになるから注意しろｗ

スーファミでwindowsなら動いたよな

人知れずファミコン上で動くＣコンパイラを作っても、実行バイナリがとてつもなく小さい物じゃないと作れないとかで、ポシャってるのが幾つもある悪寒。

スーファミでも 10 メガ ROM とか言って 10Mbit だったのはﾜﾗﾀ

メモリチップはビット数で数えるからね。

>>221
FCでセルフコンパイラなんて酔狂な奴もそうそういないと思うが。

ファミコンでも地球シュミレータは動作する事実！
おまいらその程度もしらないのか？

そんな計算量こなせるならN64エミュレーターとか屁の河童だよな。

>>225
シム・アースが出たのはスーファミだったような気がするけど…

>>221
人知れずっていうか、6502のCコンパイラはあるだろ。

ファミコンの狭いメモリーに、ソースと実行ファイルとワーク領域と置かなきゃならんのにか！

ソースは1パスだから常に全部保持する必要はないだろ。
だからといってめちゃくちゃ余裕が生まれるわけでもないが。

8bit機でメモリ効率考えて作るならマクロ的な機能が豊富なアセンブラもどきが一番だろ

ファミコンって「ソフト」がハードウェアそのものだから、無限の可能性があるよな
Cコンパイラを走らせる、なんてのだって、こだわらなきゃカートリッジに石積んでやらせりゃいいんだし

もういいよ。

またトンチンカンな事を言う奴が沸いたな。

ファミコントレードで株取引もできる

>>230
ファミコンってハードディスク付いていたっけ？

結構、ディスクシステムのディスクは固かったな。ハードだったな。

でもまあホントはクイックディスクなわけだが。

トンカチエディタ最強。

ここはバカしかいないのかｗ

ほとんど何言ってるのかわからんけど、
自分が遊んでたゲームがどういう苦労の上に作られたのかが何となくわかったような気がする。

FF3とか当時なんとなくゲームやってたけど最近この手の話を見聞きしてからは見方変わったし。

デザイナーなかじまかおる

ファイナルファンタジーのプログラムは、それぞれのエフェクト担当が勝手気ままにプログラム組んでるらしくて、エフェクトとエフェクトを繋ぐ変換処理が色んな所に埋め込まれてるよね。

PS以降の話？

>>238
自己紹介乙

( ﾟAﾟ)y-･~~腹立つわーこいつらー…

http://love6.2ch.net/test/read.cgi/kao/1179929773/

コピペ君って馬鹿だな、まで読んだ。

6502はズラ語信者用のアイテム。


Cで組むの試してみたよ。RAMは何とかなる。ROMはちと頭ひねる。
6502用のCは6502向けの拡張仕様持ってるからケチりたければ使う羽目になる。

PICをCでやるのと似た感覚。組み込み程度の簡単なソフトなら何とかなる。

Z80ならCでまだ組める。


何が問題になるか。256バイトのスタック。汎用レジスタ1個。ポインタ。

6502でCを使うとどんなコードを吐くのか気になる。
intは片っ端からゼロページに割り当てていってデフォでstaticとかね。
autoはさすがに256バイトのスタックでは無理がありそう。

普通のCPUでアセンブラとCで同じ処理を書くと、サイズは少なくとも2〜3倍になる。
速度差も計測してはいないがサイズ比でその程度だろう。

6502に最適なコンパイラはGAMEではないかと思ったり。

ゼロページに置くのも専用命令でした。
直さないと1ページとかに置かれます。
ゼロページはI/Oに使ったりするからかな？


大昔、アセンブラ覚えた頃にC薦められて、勉強しようとして、
「ワークエリアの自前管理（絶対番地への配置）ってどうすればいいのかな？」
と本気で悩んでました。

ああ、そうか。
6502はI/Oポートを持ってないからメモリマップトI/Oになるんだね。
68系と同じか。

クセが強いのでアセンブラでちまちま組むには最高に面白い反面、
コンパイラにとっては手強いCPUなのかもしれんなあ。Yレジスタの
インデックスモードなんて便利な命令にも落としにくいし。

と言うか6502に (xx),Y ってインデックス・モードがないとすると
最高に使いにくいじゃん。

むしろコンパイラ作りやすいCPUだろ

コンパイラはあるだろ…6502はかのApple�Uに詰まれてたんだから
だが6502がつまれている＝Cで開発できる は成り立たない…

ファミコンのハード仕様でメモリ量がスタックを多用するCに向かない。
ROM、RAMのページング(カセット内の領域切替)が独特すぎて対応できん。

とくにメモリから来る制約はかなりきついかと、あと6502はスタック操作には
向かないチップだったと思うが？
といった理由からファミコン、スーファミ、ゲームボーイのゲーム開発はアセンブラ
だったと思う。(ゲームボーイならC＋アセンブラでの最適化もありえるが…同人系で)

スタックを多用するかどうかはコーディグ次第なんだけどね。
ま、レジスタ少ないからゼロページをレジスタとみなして引数として使うのは普通で
スタックはサブルーチンコール時のポインタを置く程度なのは常識。

見方によっちゃあ、グローバル変数だらけの醜悪プログラムだろうなw

ただでさえ2kだったかそのくらいのRAMしか積んでいないのに
ファミコンは…

0ページのレジスタ代用…明らかにそうさせようとしているアーキテクチャだ6502
たしか6502は似非劣化型6800だったと
インデックスが8bitになる代わりに2本になってspも8bitになって1ページ限定化
バイトオーダーがリトルエンディアンからビッグエンディアンになってたはず…

まぁおまえら落ち着け。
最初はコンパイラがあるなら言ってみろ
だったのに、コンパイラを例示すると現実的じゃないとか、
話題の切り替え、すり替えがひどすぎるだろ。

典型的な負けず嫌いです

360はC♯

ファミコンって今の激安PCよりはるかにショボイPCでソフト開発してたの？

そりゃあんた、「今の激安PC」のスペックは、一昔前のEWSを凌駕するんだからねぇ。

ファミコンソフトってどんなスペックのPCで開発してたの？

カシオのポケコンと紙

PCが進化しなければ4MBitカセットのゲームも作れなかったに違いない。

>>262
CPUはZ80
メモリは64KB
1MBフロッピー（8インチ）x2
OSはCP/M

他の会社は知らないけどね

>>265
当時は数百万してたのかな？

>>247
> autoはさすがに256バイトのスタックでは無理がありそう。

autoは、ハードウエアのスタック使わなくても実装できるじゃん。

ちなみに、PC-6001, SHC-25辺りの開発にも>265と同等のスペックの端末を使っていた。
ファミコンと違って、CPUが同じだからその分楽かもね。

>>265
こんなんで作ってたんだ
今はどんなPCで作ってるんだろ？

任天堂純正の開発機材は数百万したらしいが、どんなもんだったんだろう？
ファミコンとPCが繋がってて、ROMライタで焼かなくても動かせたり、リアルタイムに
デバッガ使えたりとかしたんだろうか？
売れ残りのPCにアセンブラと開発用の資料つけただけのボッタクリ、ではなかったと思いたい。

>>270
pc88伝説本には一千万したって書いてあった
ファミコンのテクザー開発時は機材が買えなかったとあったけど
ｐｃ88上で作ったのかな？

Z80秘伝の書の人は、PC88のゲームをPC88で作っていて、それを知った人が驚くとか書いてたね。

そんな高額な開発機材なんていらん気がする。
もちろんROMカートリッジをエミュレートするような何かは必要だろうけど。

ICEみたいなデバッグ環境って今も昔も使わない人は全く使わないよね。
俺もしがない組み込みPGだけど、デバッガの類はまったく使わない。

ちょっと待て。ICEはデバッグツールだと思っている?
勘弁してくれ。

もともと語義からしたら確かにデバックとは無関係だけど、
しかしデバッガを使わないならICEである必然性は何もないでしょ。

すでに書いているように、ファミコンの場合なら単にロムカートリッジを
エミュレートすれば事足りる。

いや、ファミコンソフトならある意味どうでもいいけどねぇ。
私ゃ>273が作った装置を使いたくないぞ、と。

>>274
え？違うの？ｗ
Z80だけど、ダンプしたり、リード／ライトブレークかけたり、ヒストリ見たりしてたよｗ
ROMエミュレータはCPUにデバッグ機能が付いてないとアレだしなぁ

ICEをデバッグにしか使ってない⇒評価ツールとして使っていない⇒信頼性テストしてないの?

評価ツールってなんのことか意味不明だと思うなw

HW起因のごくまれにしか起きない不具合とかにぶち当たったとき
ICEってデバッグにすごい役に立つと思うけどなぁ。HW起因とすら、
わかっていない状況では。

「このメモリにはCPUからしか書かないし、HWブレークかけても
ひっかからない！なのに化けてるのは、HWのバグだ！」

テナ感じに。

なんだファミリーベーシックじゃないのか

>>280
デバッガなんてぬるいものはいらん。
デバッグプリントができる環境があれば必要十分。

普通はそれそらいらない。
挙動から問題点が推測できないようなら、プログラマとして余程無能か
コードの書き方が根本的におかしいんだよ。
HWのバグの発見だって同じこと。

デバッガがなきゃデバッグできないとかいうやつが組み込み業界も多いけど、
そういう奴みるとアホかと思うよ。

>>282
お前、ケツメドにハンダごてねじ込むぞ？少し黙ってろ。

>>282
まぁいわんとすることはわからないでもない。少数精鋭の
小規模開発である場合とか特殊な条件つければ、言っていることが
成り立つような状況がないことはない。

だけどデバッガというのは、自分の身を守るためにも使えるのよ？

さっきの例じゃないが、ICE使ってすぐにHW起因であること
を示せれば、あとはHW屋に投げればいいので精神衛生上良い。
原因の切り分けが、明確に出来てないのに、「ソフトは正しい！
あとはHW屋でやれ」っていっうのは傲慢なんじゃないかなぁ。

そして、この切り分け作業というのは、デバッガやオシロ、ロジアナ
なしには、相当な困難を極めるわけで。

> デバッグプリントができる環境があれば必要十分。

えっと…↑ここで笑えばいいのかな？

>>285
ひょっとしてデバッグプリントっていうのはデバッガ使う、とか思ってるの？w

ファミコンにプリンタついてんの？

>>286
逆でしょ。組み込み云々の話をしているのに「デバッガがぬるい」とか「デバッグプリント」とか言ってる>282がすっとこどっこいなんでしょ。

>>287
ファミコンと同世代のSEGA SC-3000には4色プロッタプリンタがオプションであった

ある程度当てがついている状態でデバッグプリントが使えるなら、デバッガはいらんな。

よくわからんがおまえらが凄腕であることはわかった。

凄腕？んなわけない。ただの化石だろ。

そんなのおそまつ君の出っ歯だろ当然

プログラムにデバッグ用のコード埋め込むと、タイミングとかズレて虫捕りできないケースもあるんだよ。
かといって、インサーキットエミュレータがタイミングバッチリかと言えば、別の意味でタイミングがズレたりするんだなこれが。

デバッグプリントのせいでスタックの状態が変わったりするしな。

そういえば、昔は遠藤雅信氏が、２ちゃんに書き込みしてたよなあ。
このスレに、召還されないかなあ。。。？

自営業だったらすぐに召喚できるんだけどなぁ…

>>287
毛糸の絡み具合を操作することでグラフィック
を出力する、プリンタ的なものならあった。

>>270
純正機材は値段が言い値のぼったなだけで性能は全然大したこと無いだろ。
スペックコスト比で言えば当時の10万程度のPCと変わらん。

なんか知ったかぶりな人が来ましたよ

当時、10万+程度で買えるPCなんて存在しなかったのだが。

appleII+Romライタでやってたのかとおもったっす

>>301
90年代の前半とか、エントリーマシンでも、4,50万してたな。
そういえば。

>>301
言いたいことの意味は分かるが、言葉尻だけについて言えば
んなことはない。

MSX？アレはゲーム専用機だろ？

>>299がバカなのは「純正機材」と言う単語を意味も分からずに使っているところ

TreeViewとListViewにｘVN_GETDISPINFO相当の機能がなかったので、
Controlから派生させて自作したよ('A`)
（VirtualModeもパフォーマンスがよくなかった・・・）

C#だとAPIや定数の定義が面倒だが、C++/CLIだとWin32ヘッダそのままインクルードして使えるから楽でいい。

だがそんなことするくらいなら最初っから
つMFC

・・・そんな感じだ。

>>308
誤爆ｽﾏｿ

ファミコンで一番最初に発売された「スーパーマリオブラザーズ」って
アセンブリ言語で作成されているの？
プログラムサイズが40KBとか聞いたのだが・・・

256kbじゃなかった？
っていうか、わざわざCとか使う理由がないでしょ。
アセンブラが難しいとか思ってるのならそれは誤解だよ。
いろいろ面倒ってだけで、じつはCなんかよりずっと簡単。

ファミコン用のゲーム開発で使っているアセンブリ言語って

ldx #$0
ldy #$0

とかってやつでしょ？
こんなんで40KB分も書いたのが凄いと思うんだが

プログラムサイズ内に、データを一切含んでいなければね。
通常、どんなプログラムにもデータ領域は含まれているわけで。

マップやサウンドのデータがほとんどでしょ
つーかマリオの頃ってまだバンクとかなくて最高32KBだったんじゃ

マップにしても、雲と草で同じドット絵を使いまわしてたんだよね？
色だけプログラムで白と緑に塗りこんでたんだよね？
画像処理系の知識がない俺にとっては、塗りつぶしのアルゴリズムや
画像重ね合わせのアルゴリズムからして難解なものに思えるのだが・・・

色はカラーパレットの変更だけだし、
（カラーパレットとは1という番号で示される色が実際何色かというデータのこと）
画像重ね合わせも、透明色があるから普通に描画するだけ。


と知らないけど適当に言ってみる。

ファミコンはとてもチープに出来ているので、グラフィックVRAMを持ってない。
VROM上に予め定義されたパターンテーブルの8x8キャラクタを、タイル状に並べて表示
する「バックグラウンド」と、キャラクタを任意の座標に表示させる事ができる
「スプライト」の、2つが存在するのみ。(画面ではないが、背景色も指定できる。)
これらはハードウェアによって自動的に1つの画面に合成されて出力されるので、
プログラミングの際に重ね合わせ処理を記述する必要はない。
スプライトとバックグラウンドを重ねるのでなければ、予め重ねてあるパターンを登録
しておく以外に、重ね合わせたように見せかける方法はない。

>>301
AmigaとかAT&Tとかじゃないんだから

大昔コナミのグラディウスとイース�T�Uを解析したことがあるけど、マクロアセンブラ程度
タイマー割り込み処理によるイベントドリブンなプログラミング手法はすごく参考になった。

>>301
十万円台で、ってことならPC-8001とかMZ-80Kシリーズとかあったね。
十万円ちょっとだと FM-7、十万円以下だと PC-6001、VIC-1001 (Commodore 64) とかか。

結構売れてた。

>>319
開発をFDじゃなくてカセットテープでやるの？
クロスアセンブラ（除くVIC）動くの？つーかあるの？

何言ってるんだ、クロスアセンブラなんて、ちょちょいのぱーだろ。

漏れが使った某PC開発環境では、クロスアセンブラの出力するバイナリをSフォーマットに変換した記憶がある。

> クロスアセンブラの出力するバイナリをSフォーマットに変換した記憶がある。

それがどぅしたｗｗｗ

PC-8001 (or PC-8001mkII)　で CP/M なら確かクロス環境はほぼ揃ってたと思う。
ディスクユニットにせよソフトにせよ PC 本体並に高かったけど。

逆に当時 CP/M 以外何が使えてた？

純正機材の中身は当時10万のPC程度
↓
当時10万のPCなんて存在しねぇ
↓
PC-8001とかMZ-80KシリーズとかFM-7とかPC-6001とかVIC-1001とか

って話になんでクロスアセンブラが出てくるのやら

>>324
いや悪いけどさすがにそれは君の読解力の方の問題だと思うぞw
ここ（に限らないが。。）は一人の人間が語ってる場所じゃないんだから
話題は複数同時展開することもあるでしょ。

まあマルチスレッドの映画や小説みたいなもんだ。

何言ってるんだ、お前ら？

このスレは年齢層が高い。
明らかに三十路の壁を越えている

４０超えてんだろ。

ファミコン当時のアセンブラの話題とかリアルタイムで知っているとしたら30代後半でギリギリだな

エラーインクルードファイルがオープンできないとはどういうことか教えてください。
お願いします。

最近 Intel-8086 系 CPU 用のアセンブリ言語を勉強しているのですが、
これってファミコンのアセンブリ言語とどのくらい違いますか？
書き方（文法）が全然違うのは分かっています。
レジスタへのロード文からして、
mov al, 100
lda 100
のように違うことから分かります。
自分が知りたいのは、実質的な機能面のことです。
例えば、Intel の方のアセンブリ言語には、
mul（乗算）やdiv（除算）などの演算命令や
loop（反復）の命令が存在しますが、ファミコンの
アセンブリ言語にはあるのか？といったことです。

http://en.wikibooks.org/wiki/6502_Assembly

コピペ君って馬鹿だな、まで読んだ。

>>332
ありがとうございます。
英語なので解読に時間が掛かりそうですが・・・

ファミコン開発にPC9801使ってた奴らはみんなモグリだろ。
任天堂が当時サポートしてた機種は富士通のじゃなかったっけ？

よくも知らない業界のことを適当な知識で話すな

開発機材はシャープ＆ハドソンの黄金コンビだった気が。

任天堂がまだただの花札屋だった頃、富士通にファミコンの共同開発を持ちかけたが
富士通は鼻で笑って相手にしなかった

富士通はないよ

不治痛・・・

オレがファミコンの開発をやったときはたしか富士通だったけど。

強制購入させられるのはHP製のICE

ファミコンソフトの開発って、スタートラインに立つまでにどのぐらいの投資が必要だったの？
>>335以降を見るとまちまちな回答が戻ってきそうな予感もするけどｗ

１．CPU抜き取ったファミコン本体に6502インサーキットエミュレータブッ刺してPC9801でクロス開発。
２．純正の開発キットをインテリジェントシステムから買ってFMR60上でラインデバッグ。（後にDOS/V機に移行）
ま、最近じゃWindwosマシン上で完全エミュレートされたバーチャル環境で開発が一番安上がりかな

6502のICEに置き換えると、画面や音をどうやってたわけ？
それが不要なら単に6502の評価ボードでいいじゃない。

安くという事になると、ROMエミュレータしかなかった。

ICEってなんだか分かってる？

インサーキットエミュレータ　の事だろ？　CPUの場合は、その機能をプローブ側と置き換えてしまうわけだ
でも CPUの停止って出来たっけ？　それが出来るならICE使えるだろうけど

普通、ICEプローブはCPUを引っこ抜いてから挿すもんなんだが。

ファミコンのCPUはサウンド機能と一緒に同一パッケージ内に入ってるわけで、
そのＣＰＵを引っこ抜いてしまうなら、サウンド機能も入ってないといけない。

単なる6502エミュレータなら、そのサウンド機能一体のICの上にかぶせて、
元のチップからCPUだけを殺す裏技が必要。

あるいは音やDMAを我慢するか

ファミコンのCPUにサウンド回路なんか載ってねえよ。
むしろ十進演算や16ビットアドレッシングが省かれてるからスタンダードな6502用の開発環境だと面倒だったってくらい。

ＣＰＵと同じチップに入ってるのであって、ＣＰＵに乗ってるとは誰も書いてないぞ？

デシマルモードは確かに削られてるけど、間接アドレッシングとかは全部そのままなんだが。

ファミコンのCPUっていったら、普通2A03でいいんじゃないの?
音源も載ってるじゃん。

>>347
あるよ。
以上。
↓次どうぞ

保守

ほとんどの話についていけないが
正直『初期』ウィザードリィは、無理。
スタート地点、今でいう地下何階だと
…たぶんポルナレフＡＡ推奨状況だよ。

ＨＰ＝１や２は当たり前。
スタート地点は地下四階。
登場モンスターも地下四階。
いいじゃないかゆとり化しても。

…知る前から良くレベル１で突撃したけど。
ＨＰ８でも色々ギリギリすぐるから、あれ。
慣れないアクションの自機並み死亡率。
ＰＳ：独特の内部構造はＰａｓｃａｌか…。

ところで、シャープのポケットコンピュータシリーズについて…？
液晶のアドレスの計算は「もっちもち※」だったけれど、
ＰＯＫＥ＆ＰＥＥＫ＆ＣＡＬＬ、楽しかった…。

※ネバツキ最大時に手に付いたままあちこちさわった状況
…いや、そうとしか表現しようのないアドレス配置ですた…

それが「ライトユーザー」だった反ゆとりジュネレーション

…すいません、『マイコンピュータを〜』世代なんです＞＜
（ブルーバックス）　Ｃ言語？何それ美味しいの？　時代。

その歳でその文章とはかわいそうに・・・

age

ｌ

ｐ；

；

；

色々な言語で書いても結局は機械語に翻訳されるんだろ？

色々な言語覚えるより、機械語覚えた方が早くね？

早くはないな…。

でも、最終的にどんなアセンブリに変換されるのかを追えずに
高級言語使うのはPC以外のソフト屋から見るとレベル低。

PCソフト屋さんとか、.NETになるとそうも言い切れないが。

ファミコン現役当時のゲーム前提なら、比較対象をCとして考えると
アセンブラを覚えた方がずっと早いだろうね。

単純に言語の学習に要する時間を考えても、コーディングの効率の点から言っても。

Cは高級アセンブラとか言われるけど、本当はゲームのように直接ハード叩く用途には
使いにくい場面も少なくない。

特にCPUが特殊なアーキテクチャだったり、ファミコンのように特殊なハードならなおさらね。
まあ当時6502用のCコンパイラがあったかどうか俺は知らないけど。

AppleII に使われてたんだから有ったんじゃない？

>>364-365
お前知ったかぶりの王様だなｗ

>>365
よく知らないなら黙ってろ。
プレステみたいに大きなメモリと速いCPUがあればCでも充分ゲーム作れるよ。
6502はレジスタのビット幅も、数も、スタックのサイズも、何から何までCに向いてないから
みんなアセンブラで書いてただけだ。

・当時は手ごろなクロス開発環境がなかった。
・当時は適当な性能のコンパクトなコードを出すCコンパイラがなかった。
・当時は作らせる側の知識がないから作るためのコストを掛けたがらなかった(今もかw)。

>>368
チミって人から「よくらからない切れ方をする奴だ」って言われるでしょ？w

つーか唐突にプレステとか意味わかりません。

というかさあ、こんなスレにいるんだから大概40前後のオッサンが多いはずだと
思うんだが、いい歳こいてわけのわからない絡みかたするなよな。
近頃本当大人になりきれない「とっちゃん坊や」が多くて困るよ。

>>367とか>>368とか。

俺(365)の言ったことが間違っているというのなら、
くだらないクダ巻いてないでストレートに反論しろよ。

俺は当時仮に6502用のCコンパイラがあったとしても、
学習コストにおいても開発効率においてもアセンブラに劣るだろうと
簡単な理由を添えて書いた。

これ何か間違ってるか？

素直な疑問なんだけど仮に6502用のCコンパイラが
存在したとして、255文字を超える文字列はどう扱うのだろう？

たぶんCはサブセットで文字列長が255文字(ヌルターミネータ
文字を含む)とかに制限されてるんだろうけど。

ドラクエとかFFとかでそんな長い文字列はみたことないです（　＾ω＾）
文字も平仮名とカタカナと数字だけだったし。

手元に6502プログラミング技法って本があるんだが、
6502のスタックポインタでさえ8ビットでこれではさすがに
小さすぎるので、ソフトウェアで16ビットSPを実現する
技法が載っている。

多分文字列に限らずデータが255バイト長を超える時は
そのようにするんだろう。

ちょうと8086が64KB境界をまたぐ時にポインタ正規化を
行っていたように。

>>371
おまえはいい年をして、まず馬鹿にしてからでないと議論もできないのか？

>>371で後半を省いてるのは重視してないのか、恣意的なのか知らないが、

＞Cは高級アセンブラとか言われるけど、本当はゲームのように直接ハード叩く用途には
＞使いにくい場面も少なくない。
＞特にCPUが特殊なアーキテクチャだったり、ファミコンのように特殊なハードならなおさらね。

これは「ゲーム機、特にファミコンはハードを叩くからＣは向いていない」という意味だろう。
そんなことは無いからプレステを例に挙げて（別にx68kでもいい）、Cでゲームを作る
こともハードを叩くこともできる、と反論したんだよ。
ファミコンでまともなCコンパイラが無いのはゲーム機だからでもハードを叩くからでもない。
Cに向いてないCPUだから、それが一番の理由だ。

>>375
「できる・できない」じゃなくて「向いてない」って言ったんだよ。わかる？

Cは確かにアセンブラチックなことができる言語だが、アセンブラと完全に
同じことができるわけでもない。

こうやって噛み付いてくるということは、たぶん君は8bit程度の石の
アセンブラ書いた経験なしに言ってるんだろうけど、実際にそうなんだよ。

どうしても隔靴掻痒的なところというのがある。

うまく伝わるかどうかわからないが、例えば
「ここでレジスタの値とメモリの値を交換する命令が使えれば高速化ができるのに」
という場面があっても、Cではそんなもの当然サポートしてない。

あ、上で8bitって書いたけど、本当は8bitに限らないよね。
X68Kの文化はあまり知らないけど、ハード叩くソフト、例えばPCM8（だったかな？）
なんかは当然アセンブラだったでしょ？

それどころか、WindowsXPの時代だってデバドラなんか（もちろんCがメインとは言え）
きわどいところはやっぱりアセンブラで書くらしいよ。俺自身はデバドラプログラミングの
経験はないけどね。

互いに「相手は分かってない」という前提で、おっさん二人がそれぞれ一人喧嘩してるように見える。

あー読み返してみると上の文章じゃたぶん伝わらないなあ。。

「それはハード叩く用途にアセがより向いているんじゃなくて、
単にパフォーマンスの最適化に向いてるだけだろ」って言い返されそう。

まあそれは半分はそうなんだがそればかりじゃないんだがなあ。。
俺の説明能力じゃなんとも説明しにくい。
6502のアーキテクチャもニーモニックも知らないしw

>>376
お前＞ハードを叩くようなゲーム機ではＣは使いにくい（から、ファミコンではアセンブラだった）
オレ＞理由が違う。６５０２ではＣはムリだからアセンブラだっただけ。

っていう議論だっただろう。

だのに>>376では「Ｃはアセンブラとまったく同じことはできない」とか
「１６ビット機でもアセンブラを使うことはある」とか、違う話になってるぞ。

ていうか、>>379・・・・・６５０２よく知らないって・・・・・
そんなんで人には８ビットＣＰＵのアセンブラの経験がないだろうとかよく言い切れるな・・・
そんなんじゃ「６５０２ではＣはムリ」っていくら言っても通じないじゃん。
ていうか最初に言ったとおり「よく知らないなら黙ってろ」で終わりじゃんか。

何を勝手に誤解して勝手に熱くなってるんだろう。
まあそう熱くなりなさんな。

俺は
＞ハードを叩くようなゲーム機ではＣは使いにくい（から、ファミコンではアセンブラだった）
こうは言ってないよ。

ファミコンでCは使いにくい「から」アセンブラが使われたのだ、なんて言ってない。

仮に当時Cコンパイラがあってもアセンブラが使われるだろう、とは書いたし、
その理由としてアセンブラの方がトータルでより効率的だから、とも書いたが。

しかし君っていったいなんなの。
いきなり喧嘩腰で人に突っかかってきて。
君みたいなタイプが朝の駅で駅員に食って掛かったりするんだろうねきっとw

もういいよ。
おまえがど素人だということは、よくわかった。
おまえは憶測で人を馬鹿にしているようだから（駅がどうとか）、オレは事実でお前を遣り込めることにするよ。
おまえは6502も知らないし、x68kも知らないし、デバイスドライバの書き方も知らないのに、
ファミコンがどうの、Ｃがどうの、アセンブラがどうの、と延々と語ってたって訳だ。バカバカしい。
よく知らないなら、>>381みたいに、駅のことでも書いていればいい。
プログラムのことには口を出さないことをお勧めするよ。

ど素人ねえw
当時のファミコンのコード書いていた人なら、まちがいなく俺の意見に
賛同すると思うけどね。

だって事実だからねえ。

ちなみに細かいようだがx68kじゃなくてX68kじゃないのか？
x86じゃないんだからさw
いやまあこれは言い掛りに近い突っ込みだとは俺も思うが。

・6502用の実用的なCコンパイラはある。変わってはいるけどCに不向きというわけではなかった。
・敬遠された理由は、オブジェクトコードが増える＝ROM容量が増える＝コストが増えるから。
・速度的にはコンパイラによる最適化をかけてやれば、ゲーム用途でも十分だったりする。
・実際、8bit CPU向けの業務用なCコンパイラって、いくつもあるんですよ？もちろん6502も。
・ただ、ファミコン当時の環境から考えると、あまり現実的ではなかったかも。
・ただし、ANSI以前の時代なんでフル規格かどうかを問うのはナンセンス。

ASCII誌だったかにGAMEコンパイラ載ってなかったっけ。
まあ昔のPC板向けの話題になるのであまり深入りは避けるが
そこそこ使えたような記憶がある(Apple][)

もしかして知ったかぶりの王様って言われたのが癪に障ったのか？
悪かった謝るよ、ゴメンゴメン

>>387
人間は自分の中にない物を人には言えないもの
お前が知ったかぶりの王様なんだろうが

>GAMEコンパイラ
GAMEIIIじゃなかった？
あの手のインタプリタ付きコンパイラなら6502でもそんなに難しくないけど
本格的なＣのコンパイラ作るのはかなり面倒くさい
アセンブラでも何かと面倒なんで（spが256byteしか指せないとか）
Sweet16という16bitCPUのエミュレータみたいなのがあった位

スタックは256バイトあれば十分だろう。
スタックを大量に消費する方法で実装するのなら、それはする奴がアホなだけだし。

まあスタックもっと貧弱な8051やPICでもCコンパイラはちゃんとあるからね。

>>390
再帰とかスタック上に一時的に大きなオブジェクトを
取る事は全くないの？馬鹿なの？

>>392
当時のゲームで再帰とかないでしょ。
スタックにオブジェクトってそんなこと今だってしないでしょ。

っていうか当時は動的なメモリ割り当てってのはあまりしなかった（できなかった）
はずだと思うよ。

まあ8ビットの時代は1バイトとの戦いだったから、今の
感覚で語ってもな・・・・

>>392
CPUやメモリのスペックを無視した設計をするあんたの方がよっぽど馬鹿なんだが

ファミコンソフトってHSPで作れますか？

>>388
ゴメンゴメンｗ

皆さんプライドがお高いようで

知ったかぶりの王様ｗｗ

ネオジオのゲームってアセンブリで開発されてたんだってさ。
それより前のファミコンなんかがアセンブリでもおかしくはないと思うが。

そりゃ、当時はなにで作られていたかって話ならアセンブラでしょ。

ネオジオはメインMPUが68000だからなぁ。
あの石は「アセンブリ言語は難解」ってのが全く当てはまらない。

6502だってそうだが。

あの石ｗｗｗ
アセンブリ言語は難解ｗｗｗｗｗｗ
メインMPUｗｗｗｗｗｗｗｗｗ

68000のアセンブリ言語は高級言語並に美しいからね。
6502はクセがありすぎて美しくない。

また知ったかぶりの王様か

両方つかった上での感想だが？

初代FCで初期にあった将棋ゲーのアルゴリズムが超早かったのが
今でも謎です。アセンブラでも早すぎて。

>>405ってCやC++も高級言語だと思ってるんだろうなぁｗ

>>405
6502自体に癖があるんだから当たり前。

>>405
X68kのCコンパイラ1.0には「ポインタをゼロ比較すると正常に動作しない」というバグがあった。
原因は、
move.[bwl] addr, dn
はゼロフラグ変化するのに、
movea.[wl] addr, an
は変化しないのだが、作成者がその仕様をうっかり忘れて、後者でも
beq foo
などというふうにコーディングしてしまったのが原因なのだが、これって美しいと思うか？
（何でアドレスレジスタへの代入ではフラグが変化しないのかの理由もちゃんとあるが、ここでは伏せておく）

また、リロケータブルな実行コードを出力したいとき、
move.w d(pc, rn), dn
は出来るが、逆は出来ないため直交性と言う観点からは美しくないが、これについてはどう思う？
（こっちも理由あるけど同上）

おっさんクセースレだな

なんかいつの間にか68kの話になってる。

68kはニーモニック覚えた程度でついぞ大きなプログラムは書かなかったんだけど、
確かに俺も言われてるほど綺麗なアーキテクチャだとは思わなかったな。

まあ実際使ってみないとわからない機能美って奴があるのかもしれないけど。

今の技術についていけないジジイどもの思い出スレ

ジジイつったってせいぜい40代だと思うぞw

今の技術 ^_^

>>409
普通は高級言語ですね。それ。

>>411
無論、データとアドレスを明確に区別する68000のアーキテクチャは美しい。
moveと同じようなフラグ変化が起こる事を期待してmoveaを用いるのがおかしい。
アドレスの転送やアドレスの増減で、データ演算結果を示すCCRが変化するべき理由がどこにもないし、変化するべきではない。
アドレスに対して何らかの比較が必要なら、cmpaを用いてば済むだけだ。その方が可読性も増す。
データとアドレスの区別をつけるという概念が欠如していたプログラマの方に問題がある。

インデックス付きプログラムカウンタ相対がdestに指定出来ないのも美しい。
PCを介するということは、プログラム領域が対象になるということ。
プログラム領域は参照専用のメモリ領域であり、値を変更できる必要がどこにもない。
変更が必要になるデータはデータ領域に配置して、アドレスレジスタ間接でアクセスするのが正しい。

>>418
うるさい

>>418
１００点。
だがそれはあくまでも「アセンブラとしての美しさ」であり、それなら６５０２にもそれなりの
ポリシーがあり、６８０００は美しく６５０２は癖があるという主張の裏づけにはならないが、
そこの説明はどうする？

いわゆる16bitと8bitのMPUのアーキテクチャを比較して何がしたいんだこの人は？ｗ

・人間を無視したリトルエンディアンを採用。この時点でかなり美しくない。
・汎用レジスタが1本しかない。あるシステム上で動かすプログラムを設計する時、
　システムが食い残したゼロページの使い方に頭を悩ませる必要がある。そして、
　大抵は、足りなくて泣く事になる。
・ADD・SUBを用意せず、計算前にCLC・SECを使わせる不自然さ。
・なぜか無条件分岐命令がない。
・etc...

6502の設計の割り切り方は潔い。ハードウェアはシンプルで高性能だ。職人芸に挑む
楽しさもある。だが、美しくはない。良くできた6502のプログラムは、芸術的なまでに醜い。
真に美しいMPUのプログラムは、人間が読んで美しく、人間が書いて美しい。

ごえんなさい6502は使った事ありません。すいまえんでした；；

結局また知ったかぶりの王様か

一行糞レス素敵ですね＾＾

>>422
無条件分岐命令が無いとか妄言書くなら
6502使ったことが無いなんて明白な事をわざわざ書く必要は無い

>>425
無条件相対分岐のBRA命令は無いよね。
絶対番地を指定するジャンプなJMP命令はあるけど。

PCエンジンのCPUにはBRAあるんだね。

>>422が言う「美しい」の定義を是非知りたいんだが（笑

>>427
6502から拡張された65C02をさらにカスタマイズしたチップだからね。
6502そのものではないよ。

6502は [zz],Y のアドレッシングモードがなかったら
これほど流行らなかったよな。

え？6502が流行った？

また無知の馬鹿が一人・・・・

6809>Z80>6502

6502ってApple][とPET2001とVIC1001と他にあったっけ？
とても流行ったとは．．．

Apple][が今のMacの礎になったんだが・・・・
まあ今もMacはPowerPCを捨ててx86になっちゃったけどね

>>433
性能ならこうだべ？
6809>6502>Z80

Macの礎はLisaじゃね
つかMacって68000だし6502関係ねーし

それを言うならPowerPCだって68000関係ねーだろ

↑お前バカだろｗ

設計思想がApple][とMacは正反対な気がする。

あと、OSだけでなくアプリケーションまでスーパバイザモードで動くように設計した奴を
殴ってやりたい。よくも68000を汚したな、と。

↑お前が馬鹿な事はよくわかった

もっと具体的に。
馬鹿というだけなら馬鹿でもできる。

>>422
ビッグエンディアンの利点って何だっけ？
なんか直感的には無茶苦茶不便そうだけどなあ。

ビット幅が違う値同士の演算とかこんがらがりそう。

ミドルエンディアンじゃなきゃどっちでもいいよ。

>>443
ビッグエンディアンの利点は人間にとって直感的で自然な配置であること。
あとはTCP/IPのネットワークバイトオーダはビッグエンディアンだったと思うんで、
そっち方面では有利。UTF-16も標準ではビッグエンディアン。68000にはほぼ関係なさそう
だけど。

> ビット幅が違う値同士の演算とかこんがらがりそう。
簡単なやつは簡単。適当に書いたから動かないかも知れない。
;例)メモリ上の128bit値と8bit値の加算(知らない人でも読めるしつこいコメント付き)
.text
LEA V128,A0 ;V128の実効アドレスをロード
MOVEQ #0,D0 ;ADDXで使うために0をセットしておく
MOVEQ #0,D5 ;ゴミ消し
MOVE.B V8,D5 ;V8から8bit値を取得
MOVEM.L (A0),D1-D4 ;A0が指すメモリから128bit値をD1-D4に読込む
ADD.L D5,D4 ;最下位から順に
ADDX.L D0,D3 ;条件分岐して加算しない場合を作るよりも
ADDX.L D0,D2 ;素直に加算しちゃった方が早いので
ADDX.L D0,D1 :最上位まで0+Xフラグを加算していく
MOVEM.L D1-D4,(A0) ;計算結果をA0が指すメモリに書き戻す
;未完 あるいは NEVER END
.data
V128: DC.L $12345678 ;最上位
DC.L $9ABCDEF0
DC.L $FFFFFFFF
DC.L $FFFFFFFF ;最下位
V8: DC.B $88

ゼロクリアされた領域に1オクテット単位で1を書き込んだのに
同じアドレスで2オクテット単位で読み出すと256が得られるのは
直感的な配置とは考えられない

> 人間にとって直感的で自然な配置であること

ｗｗｗ

つーか大文字で書くなよ気持ち悪い…

…まあ、お前だけだ。

ビッグエンディアンだからネットワークに強いって何時の話？
68000の頃?

今のCPUはメモリよりCPUのクロックの方が数倍速いから
リトル点ディアンであってもtcp/ipに不利にはなってないよｗｗｗ

ネットワーク機器に使われてるCPUを知っての発言か？

PowerPCかARMでも使ってりゃいいよ組み込みは

ネットワーク機器だとMIPSとかPPCあたりが多い気がする。あとARMとかColdfireか?
PCIとか(S)ATAみたいなPC由来のやつらがリトルエンディアンなのはデメリットにならないの？

最近は変換load/storeを持ってるのとか、ページ単位とかでエンディアンを
切り替えられたりするから、あんまり関係ないんじゃないかね。

>>445
丁寧に説明してくれたのにケチつけるようで言いにくいけど、
やっぱり最下位の値がD4で最上位がD1とか直感的じゃない気がするよ。

っていうか大概の演算でも何でもMSBよりLSBが重要な場合がほとんどなのに
ビッグエンディアンだとラベルはMSB指すんでしょ？
慣れればなんでもないのかも知れんがバグの温床になりそう。

>>454
ならないよ。両方やってきたけど、人間はどちらにも馴れることができると判っただけ。

ビッグエンディアンは使いにくいね
大体、ビッグエンディアンが見やすいとかっていうのも、人間が
「上位桁から書く」という習慣があるってだけで、
本来なら低いアドレスに低い桁が書かれているリトルエンディアンの方が合理的なんだけどな。

しばらく68000使ってたけど別に慣れればリトルエンディアンでも
ビッグエンディアンでもどっちでもいいや

Interface9月号にColdFire基盤が付属してるから、使いにくいかどうか確かめてみれば？
フリースケールが第二回コンテストやってるし。

>>454
慣れたら一緒。
機械語やアセンブリ言語のレベルなら、直前の命令を見れば、数字の桁は把握できるわけで。
それなら、単にどっちから文字の塊を読み始めるかの違いしか無いんだから。

リトルはよくてビッグはダメって言い張ってる奴は、お寺の門の上に掛かってる看板見たいに、右から左に文字が書いてあったら読めないのか？
「昔は、右から左に文字を書いていた」って予備知識があったら普通に読めるだろ。なんでコンピュータの数字は読めないんだよ。
リトルは読めるけどビッグだと本当にダメってなら、脳の障害を疑ったほうが良いぞ。
実際に、脳の障害で、左右のどちらか一方側から読んだ時しか、文字の塊を単語として認識できないって人は居るから。

確かに、リトルエンディアンの方が、CPUの回路の実装は、ちょっとシンプルになるが、結局は、それ以外の点は、単なる慣れの問題だよ。

＞リトルはよくてビッグはダメって言い張ってる奴は、お寺の門の上に掛かってる看板見たいに、右から左に文字が書いてあったら読めないのか？
↓
＞リトルは読めるけどビッグだと本当にダメってなら、脳の障害を疑ったほうが良いぞ。

なにこの馬鹿丸出しの飛躍っぷり

ていうか仮定が馬鹿丸出し。

「リトルはよくてビッグはダメって言い張ってる奴は」「右から左に文字が書いてあったら読めないのか？」
なんでそうなるの？意味ワカリマセーン（笑）

>>459
ご高説に茶々を入れるようで申し訳ないが
「昔は、右から左に文字を書いていた」んじゃなくて、
あれは一行一文字の縦書きなんだよ・・・

予備知識がなくてもちゃんと辻褄はあっているのさ

敢えて茶々を入れるが、「一行一文字の縦書き」なんて知識なしにそう認識する奴はいないと思うよ。

ああ
日本語は縦書きが基本という予備知識は必要だな
横書きという概念自体輸入物だ

言語学板でやれ

PCエンジン版のツインビーなら仕事で作った事あるぜ

ツインビーで最も良いのは出たな！！とヤッホー！。
X68000版の出たな！！の移植度は賞賛に値する。

だがPCエンジン版は音も絵もよろしくない。絵はまあ仕方ないものと我慢しよう。
だが音はROM2にしとけば劣化回避できたはずなのに。
ローディング時間なんて飾りです。偉い人にはそれがわからんのです。

PCエンジン用のゲームとしてはよく遊べる部類だが、移植として見た時にはつらいクオリティ。
よくもやりやがったなコノヤロウ！という出来だった。

すぐ俺が俺が！になるから
ちょっと頭冷やして過疎ればいいよ

プログラムに触れていると
昔昔、ファミコンやスーファミ時代の記憶が蘇ってしまう。
ああ、今になってあの頃を思い出す事になるとはなぁ…

おにゃん子タウンとか
ファンキーモンキー西遊記とかあれ高度なプログラマーなの？

>>470
高度かどうかは兎も角、少なくとも“プログラマー”ではありません。

今来た。こんなスレあんだね。
元FCPGだけど覚えてる範囲で書き込んでみる。

アセンブラでつくられるのは容量もあるけど速度のため。
リアルタイムのアクションゲームには速度が必要。

>>265
そんな感じ。キャラエディタはもちHu(ry

>>270
そんな感じ。機材というかライセンス＋公開資料。

>>309,310,313
プログラムエリアは16kだったと思う。8kだったかも？
マリオぐらいまでのゲームは最大32kバイト。16kのタイトルも沢山あった

>>314
ファミコンにいわゆる「グラフィック」は無い。なので塗ったり線を引いたりできない。
2bitカラー（3色＋透明）の256個のキャラとそれを使った64枚のスプライトしかない（マリオのサイズは2x2=4枚）
葉っぱと雲はパレットを変えてるだけでパレットは全52色の中から指定。

長文スマソ

こんなスレがあるとは初めて知った。


昔、１回だけファミコンの仕事したことがあるが、

・PC-9801でソース書いてコンパイル
　　　　↓
・出来上がったバイナリをROMライタに焼く
　　　　↓
・ROMカセットの基板のソケットにROM挿してファミコンにセット
　　　　↓
・ICEのホストマシン(PC-9801)で制御ソフトを立ち上げてシンボルテーブルを読み込ませる
　　　　↓
・ICEのスイッチ(確か、ICEモードとCPUモードがあったような？)をICEモードに切り替えて走らせる
　　　　↓
・デバッグ

というような流れだった。

何でいちいちROMを焼かなければならないのかは、今となってはよくわからないや。
ROMエミュータが無かったか、あるいはICEにエミュレーションメモリが無かったせいかも？
(あるいは、その機能はあったけどその存在を知らなかったので使っていなかっただけ、という可能性もあるｗ)

あと、ICEモードにすると、音が出ないがシンボリックデバッグが可能になって、
CPUモードにすると音が出る代わりにデバッグが不可能になったような気がする。

多分、6502エミュレーションモードと、ファミコンから引っこ抜いたCPUで直接動かすモードの切り替えスイッチだったのだと思う。

あと、サウンドドライバは既に社内で用意されていたライブラリを使っただけなので、音源関係のデバッグはやったことが無い。

サウンドデータ(楽譜)はMMLで作ってパソコンのPSG音源であらかじめ確認してから、
そのデータをファミコンに持ってくるだけだったような気がする。

組み込みはだいたいLinuxじゃないか？
gccだと思うが。

誰に対するレスだよｗ

ファミコンの時代にLinuxは存在しないどころか、開発すら始まっていません。

gccはあったけど、ファミコン中期〜後期の頃に
最初の安定版がやっと出てきた頃じゃなかったかな？

正直、スレを間違えているとしかｗ

なんで突然Linuxの話が出てくるのかが分からん

バンクの切り替えで死にそうになった

ゲーセンにある３Dのガンダムseed destinyってC++でしょ？
あんな早い動きC++でなきゃ無理でしょ？
ガンダムクラスからデスティニーとかフリーダムとかnewしてるんでしょうか？

アホかい。

PICのCとかも使えないというんだろうな。
目的次第でしょうが・・・。

ガセのアーケードは、Linux

まんまLinux。

Linux上でゲームが動いてる。

そりゃ、ＡＴ互換機ベースのハードだからな。

>>479
ﾜﾗﾀ

>>479
おい、νをそんながらくたと並べんな。

昔はＣでゲーム作るのは珍しかったって聞いたけど。
ドラッケンはその珍しいゲームのうちのひとつ。ファミコンじゃないけど。

ハック、ハック、ドラッケン

スーパーマリオの、残機を、たくさん増やすと、王冠がついて、その後ろに、
キャラクタがつきますが、可読性に、欠陥なので、せめて、１６進数でよいので、誰か、
ハックしてください、ワールドも、同様です、、、

句読点の使い方から覚えましょう。せめて中学生レベルまで。

>>488 の文章は何かの暗号にしか見えない、誰か検証頼む。

とりあえずコード書いてみろよ

お題は、ジャンプして、踏んづけて、蹴って、跳ね返ってきて、自滅　まで

なんだこの日本語の不自由な方々は？

6502にもCコンパイラはあるにはあるけど、6502は8ビットCPU
の中でも特にコンパイラが作りにくいCPUで、Cとは言え強い
制限があった

8ビットに特化しすぎていた

そりゃターゲットに最適化したコンパイラにするのは当たり前だろう。

6502の時代を考えろよ
Cコンパイラなんていう高度なものが動くだけで感激
制限があるなんて当たり前

6502でコンパイラ動かす必要ないじゃん

Apple][にGAMEコンパイラがあったよな
これはよく出来ていた

他の機種でクロスコンパイラ動かすのもキツいな。
日本で主流だったPC-8801とかはメモリ64KBしかないウンコみたいなマシンだったんだろ？

ファミコンの後半くらいは16bit機もでただろ。

65816か
16ビットモドキみたいなCPUだな

>>501
クロスコンパイラを動かす環境のこと、

>>499
お前には想像もつかない世界だろうがこの世には
たった96KBのexe一つだけで動くFPSなんてのもあるんだぜ？

今の、資産が山ほどあるCPUとは違うんだ

レジスタがたくさんある
それに乗り切らなくてもキャッシュがある
それに乗り切らなくてもメインメモリがある
それに乗り切らなくてもHDDがある

そんな贅沢な環境はない
レジスタがない
やべえバンク切り替えだ
割り込み禁止にすんの忘れた
バグッた
レジスタに乗らねえ
おいデザイナー削れよ
うるせえよどうやったって乗らねえんだよ


とにっかく制約が厳しい

>>504
それを考えるとグラIIや魂斗羅のあたりのコナミは神だったな
カートリッジで一部機能拡張をしていたようだけど、それでも神。

ああSFCでカートリッジ上に専用LSIを載せて機能拡張を
するというのはよくやってたみたいだな

ほとんどがコピー対策だったみたいだけど

>>504
最近FCの解析に挑戦してるんですが、8086で1MBなかったのなんてかわいいもんですｗ
なんだこの仕様ｗｗｗ
まあVRAMはPPU管理下で別になってるけどそれにしても少ないｗｗ

任天堂が保有していたファミコンの開発環境
〔初期のファミコン・ソフトはこのツールを使って開発されていた＝該当ソフト：野球・麻雀〕

・台湾メーカ製のICE
（米Rockwell社の6502用ツールは、無い）
・プログラミングツール　NCAP（Nintendo-captureの略）
・ホスト機＝NECのPC-8001
・。発光ダイオード（LED）で作った8×8のドット・マトリクスから成るディジタイザ
（当時はまだコンピュータの画面上でゲーム・キャラクタを描くシステムはなかった。
ドット画データをそのままファイルとして出力できるソフトウエアがあるけど、バグだらけだった）
http://trendy.nikkeibp.co.jp/article/special/20081002/1019327/

　　　　　　　　　＿＿＿_
　　　　　　　 ／_ノ 　ヽ､_＼　　　　　　　　　　　　　UCSD Pascalで書かれているWizardryを
　ﾐ　ﾐ　ﾐ　　oﾟ(（●）) (（●）)ﾟo　　　　　　ﾐ　ﾐ　ﾐ 　P-Codeの仮想マシンを実装するのはおろか、
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼　　　/⌒)⌒)⌒)　Pascalそのものが使えないというクソすぎる仕様な
|　/　/　/　　　　　|r┬-|　　　　|　(⌒)/　/ / /／　　NES(ファミコン)になんて移植できるわけないおｗｗｗ　
|　:::::::::::(⌒)　　　　|　|　 |　　 ／ 　ゝ　　:::::::::::/　　　　
|　　　　　ノ　　 　　|　|　 |　 　＼　　/　　）　　/ 　　 　バ　　
ヽ　　　　/　　　　　`ー'´ 　 　 　ヽ /　　　　／　 　　　　　　ン　
　|　　　　|　　 l||l　从人 l||l 　　　　 l||l 从人 l||l　　　バ
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､　　　　　　　ン
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

　 　 　　　＿＿＿_
　 　　　／ノ 　 ヽ､_＼
　　　／（ ○）}liil{（○）＼　　　NES(ファミコン)版Wizardry発売
　 ／　　　 （__人__）　　　＼
　 |　　　ヽ　|!!il|!|!l|　/　　　|
　 ＼　　　　|ｪｪｪｪ| 　 　 ／

　　 ／￣￣＼
　／　　 _ノ　　＼
　|　　　 （ ●）（●）　　　　　　PascalだってApple][の内部で機械語に直しているんだから
.　|　　　　 （__人__）　　　　　　機械語が使えるNES(ファミコン)に移植できるのは当然だろ･･･
　 |　　　　　｀ ⌒´ﾉ　　　　　　常識的に考えて･･･
.　 |　　　　　　 　 }
.　 ヽ　　　　　 　 }
　　 ヽ　　　　　ノ　　　　　　　　＼
　　　/　　　 く　　＼　　　　　　　 ＼
　　　|　　　　 ＼ 　 ＼ 　 　　　　　　＼
　 　 |　　　　|ヽ、二⌒)､　 　 　　　　　 ＼

マンガ脳の恐怖、まで読んだ。

どうでもいいことだがアンセンブラってなんか卑猥なイントネーションだなw
なぜだ？

つまんね

>>509みたいなこと、Wizのオリジナルプログラマーのアンドリューかロバートがマジで逝っていたらしい・・・。

「Wizardryはパスカルでできてるからパスカルの動かないファミコンには絶対移植できない」

・・・・ってｗｗｗｗ
それを聞いてゲームスタジオのプログラマさんが憤慨。
「どんな言語で書いてあろうと、マシン語で動いてるものが移植できないわけがないだろ！」
ってんでゲームスタジオが移植を引き受ける事になったんだと。
で結果として、世界最速の操作系を持ったファミコン版Wizardryが誕生したってわけ。
その出来にアンドリューも脱帽、「数あるWizの中で一番のお気に入りは？」というインタビューで
「ファミコン版だよ。」と答えた（リップサービスもあっただろうが）って話。
まあ、末弥氏のモンスターデザインのカッコよさも一役買ってたみたいだけど。
http://fcs.main.jp/kyosyo/ends_01.html

>>513
どこかで聞いた話だと思ったら、遠藤の話か

力技で移植したのなら、あまり美談とは思わないな。
当時は基本的にはオールアセンブラで書いてたし、
どっちにしろファミコンではそういう作り方しか無かったはず

そこそこのプログラマが、AA貼り付ければ嬉しくなっちゃうマンガ脳の>>509みたいな
頭の悪いことを言うわけがない。

本来はまったく別の意味で言ってるはずだと思うね。
Wizardryがどんなゲームか知らんが、要はなんで元のコードが（あえて）Pascalで
書かれているのか考えてくれってことだろ、普通に考えれば。

ずっとBASICだと思ってた、
ドラクエ4とかをアセンブラで書くとかすごすぎるだろ

マジレスすると、ラベルもマクロもモジュール化も使えないBASICより
アセンブラの方が可読的に書けるはず。

BASICよりはアセンブラのほうが楽だろ

>>517
指摘ありがとうございます、

ついでに質問が有るのですが、
当時、任天堂から開発環境がリリースされてましたか？

昔のアセンブラはそんなに高機能じゃなかっただろ?

「そんなに」という言葉で「どんな」高機能を想定してるのか知らんけど、
ラベル、マクロ、モジュールプログラミング、
こんなのはMZ-80Kのアセンブラにすら付いてた機能だよ。

大事な点（ってこんなスレで青筋たてて言ってもしょうがないんだがw）は、
BASICは元々「とっつきやすさ」だけに重点を置くことから始まってるから、
アセンブラ程度にも大規模なプログラミングのやりやすさが考慮されてないってこと。

アセンブラにすらあるファイルスコープの概念すらないんだからさ。

アセンブラを作るのと、BASICを作るのでは、
アセンブラの方が簡単なんだよね
（アセンブラで作るじゃなくて、アセンブラ”を”作る話だよ）

そして、そこにラベルやマクロ機能を追加するのも簡単なんだよね。
高級言語と違って、ラベルは単に機械語のバイト数を数えて、ジャンプ先アドレスを
求めるだけだし、マクロは、機械語をいくつかまとめただけのもの。

生まれた時代の問題で、俺はアセンブラをほとんどしていないが、
マクロを沢山作ってライブラリ化したら、BASICとほとんど変わらなくなるなと思っていたよ。

>マクロは、機械語をいくつかまとめただけのもの
それは偽マクロ
まともなマクロアセンブラにはループもあるし記号の生成もできる
C++のテンプレートみたいなものと言えば分かるか

ラベルを追加するって、マクロはともかく、ラベルのないアセンブラなんて想像できない。
それ以前はアセンブラにラベルのない時代があったってことか?

モジュール機能も8bit時代のアセンブラとか、分割してアセンブルする以上の機能として
「モジュールプログラミング」なんてあったのだろうか。

五分五分です

アセンブラ=マクロアセンブラじゃないの
シンボルをアドレスに置き換えてくれる機能を欠くなら
それは単なるニーモニック変換フィルタな気が

>>526
アセンブラのマクロってのは、要するにCのプリプロセサと同じようなもので
ソースコードを単に文字列としてみて前処理を行う代物だよ。
なんか勘違いしてない？

>>526
>シンボルをアドレスに置き換えてくれる機能を欠く
それを「アセンブラ」と呼ぶのは H68/TR や LKit-16 くらいのもの。

因みに、シンボルが使えるというのは単なる置き換えではない。
・インストラクションによっては相対アドレスが必要なこともある
・外部シンボルの場合、未解決な参照としてオブジェクトファイルを出力する

>>526
シンボルやラベルぐらいは、ただのアセンブラでも使えるのが普通。
マクロアセンブラなら、より強力なマクロ機能が使える

へぇ〜。

先ずはMS-BASICで(今時ならスクリプト言語で)アセンブラを書いてみることだな。
イヤでもラベルだけは欲しくなる。

マクロアセンブラ？そんなものに頼るのは堕落だ。
機械語直打ちこそが

はいはい

>>515
＞Wizardryがどんなゲームか知らんが、要はなんで元のコードが（あえて）Pascalで
＞書かれているのか考えてくれってことだろ、普通に考えれば。

WizardryのオリジナルプログラムはPascal言語で書いてあって、OS自体もWizardryオリジナルのもの。
他のPCへの移植にあたっては、そのPCのDOS上でWIZ-DOSをエミュレートさせた上で
WIｚのプログラムを走らせるという手法をとってた。

なんでこんなメンドクサイことしたかといえば・・・・・。

当初はBASICで書いていたんだけど、BASICで動かしたら超激遅になることが判明したからだってさ。

Wizardryという初期のRPGゲームソフトはPascalで書かれてまして、P-codeのインタプリタで動いてる筈です。

RPGはキャラクターデータ、アイテムデータ、マジックデータ、モンスターデータ等
データ構造が命ですので、データの表現力に乏しい言語での開発は非常に困難なのです。
Pascalはデータタイプが豊富な言語なのでRPGのゲームソフトを作りやすいはずです。
81年当時のRPGのプログラムって結構凄いんですよ。当然GUIなんてあるわけないんで、
テキストだらけの黒画面を一々再描画してるようなもの凄い原始的な感じなんです。


ファミコンはApple][と同じCPUを採用していますが、ファミコンのROMカセット版Wizardryは、
FDDベースの当時のApple][版Wizardryよりも超高速で走っていて、古いファンは大きな衝撃を受けました。

Pascalに型が豊富ってどんな冗談

そ〜か〜、あん時もっと感動すべきだったのかぁ〜
かなだけメッセに、後ろめたさを感じるこたぁなかったんだねぇ

マクロもラベルも無かったアセンブラは「ある」。
PC-8801のモニタがそうだ。
大規模プログラミングなんかとても出来ないが、簡単なデバッグには使えた。
PC-8001で紙に書いたコード（の右側のHEX部)を１６進でタイプするよりはましだった。

ラベルがあるだけで(ラベルがない)BASICより書きやすくなるのは同意。
さらにマクロや分割アセンブルがあれば、もはやBASICの方が開発効率は落ちる。
BASICでもアセンブラでも仕事をしたことがあるが、前者の方がコード修正は大変だった。
BASICだと簡単な構造体すら定義できないからねえ。
もちろん今のVBとかは知らんが。Cで書けばいいから触ったこともないし。

モニタまでアセンブラに入れてるのかよ。

定義からすればモニタだろうが何だろうが
「ニーモニックをマシンコードに変換するソフト」はすべてアセンブラだが。
勝手にアセンブラの定義を狭くする意味がわからん。

モニタとアセンブラは使われ方が違うんで、話の流れ的にこれをもってくるのは無理があるっていうか屁理屈っていうか。

とかいうと、こんどはモニタでがりがり開発してた変態みたいな例をもってきたりしそうな感じだけど。

>>540
モニタってのはバイナリの編集をするためのソフトなんだけどw

N88-BASICってラベル行あったよね？

ロード、実行、ダンプ、アセンブル、逆アセンブルなどの機能を有するミニOS見たいなもんだろう。
編集だけに限定される意味がわからん。

アセンブラの話をしてるところで、モニタの話をして、なんでしたり顔なんだよ

「ROM-BASIC のモニタがワンステップアセンブラを含む」ならまだしも
「モニタはアセンブラだ」は暴言。
それだと CP/M〜Windows のデバッガもアセンブラになってしまう。

ブラじゃないよ

まあ、含んでるならアセンブラはあると言ってもいいな。

アセンブラ。情報処理試験の午後問題選択の時に出てくる！

>>549
なんかあったなｗ
簡単すぎて時間半分もいらんかったわｗ

cc65のファミコン用コンパイラで
ファミコン用のCソース公開してくださいよ。

コンパイラでソース公開は無理ですね。

"で"、じゃなくて、"専用の"プログラムを
ということです。そのような方はいないでしょうか。

ファミコンとパソコン繋げて遊ぶとかできないの？

今のwindowsにもdebugコマンドあるし
機械語でプログラム作れるけど？

ファミコンは時代遅れ

>>555

俺の7にはないみたいだけど

>>554
プリンタポートとカートリッジコネクタなりジョイスティックコネクタなりを直結すれば？

>>557
32bit版にはある、64bit版にはない。ってのはwin2k以降全部同じ。