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

ファミコンってＣ言語 ..

263:デフォルトの名無しさん
07/11/09 20:26:38
カシオのポケコンと紙

264:デフォルトの名無しさん
07/11/09 21:46:27
PCが進化しなければ4MBitカセットのゲームも作れなかったに違いない。

265:デフォルトの名無しさん
07/11/10 03:13:58
>>262
CPUはZ80
メモリは64KB
1MBフロッピー（8インチ）x2
OSはCP/M

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

266:デフォルトの名無しさん
07/11/10 03:17:51
>>265
当時は数百万してたのかな？

267:デフォルトの名無しさん
07/11/10 03:20:54
>>247
>　autoはさすがに256バイトのスタックでは無理がありそう。

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

268:デフォルトの名無しさん
07/11/10 16:44:03
ちなみに、PC-6001, SHC-25辺りの開発にも>265と同等のスペックの端末を使っていた。
ファミコンと違って、CPUが同じだからその分楽かもね。

269:デフォルトの名無しさん
07/11/10 22:07:58
>>265
こんなんで作ってたんだ
今はどんなPCで作ってるんだろ？

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

271:デフォルトの名無しさん
07/11/11 15:29:45
>>270
pc88伝説本には一千万したって書いてあった
ファミコンのテクザー開発時は機材が買えなかったとあったけど
ｐｃ88上で作ったのかな？

272:デフォルトの名無しさん
07/11/11 21:09:44
Z80秘伝の書の人は、PC88のゲームをPC88で作っていて、それを知った人が驚くとか書いてたね。

273:デフォルトの名無しさん
07/11/11 21:24:49
そんな高額な開発機材なんていらん気がする。
もちろんROMカートリッジをエミュレートするような何かは必要だろうけど。

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

274:デフォルトの名無しさん
07/11/12 01:16:16
ちょっと待て。ICEはデバッグツールだと思っている?
勘弁してくれ。

275:デフォルトの名無しさん
07/11/12 01:38:27
もともと語義からしたら確かにデバックとは無関係だけど、
しかしデバッガを使わないならICEである必然性は何もないでしょ。

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

276:デフォルトの名無しさん
07/11/12 01:44:57
いや、ファミコンソフトならある意味どうでもいいけどねぇ。
私ゃ>273が作った装置を使いたくないぞ、と。

277:デフォルトの名無しさん
07/11/12 03:11:38
>>274
え？違うの？ｗ
Z80だけど、ダンプしたり、リード／ライトブレークかけたり、ヒストリ見たりしてたよｗ
ROMエミュレータはCPUにデバッグ機能が付いてないとアレだしなぁ

278:デフォルトの名無しさん
07/11/16 20:04:25
ICEをデバッグにしか使ってない⇒評価ツールとして使っていない⇒信頼性テストしてないの?

279:デフォルトの名無しさん
07/11/16 20:48:13
評価ツールってなんのことか意味不明だと思うなw

280:デフォルトの名無しさん
07/11/16 21:38:59
HW起因のごくまれにしか起きない不具合とかにぶち当たったとき
ICEってデバッグにすごい役に立つと思うけどなぁ。HW起因とすら、
わかっていない状況では。

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

テナ感じに。

281:デフォルトの名無しさん
07/11/16 21:51:02
なんだファミリーベーシックじゃないのか

282:デフォルトの名無しさん
07/11/16 22:22:21
>>280
デバッガなんてぬるいものはいらん。
デバッグプリントができる環境があれば必要十分。

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

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

283:デフォルトの名無しさん
07/11/16 22:41:46
>>282
お前、ケツメドにハンダごてねじ込むぞ？少し黙ってろ。

284:デフォルトの名無しさん
07/11/16 23:09:45
>>282
まぁいわんとすることはわからないでもない。少数精鋭の
小規模開発である場合とか特殊な条件つければ、言っていることが
成り立つような状況がないことはない。

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

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

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

285:デフォルトの名無しさん
07/11/17 04:28:02
> デバッグプリントができる環境があれば必要十分。

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

286:デフォルトの名無しさん
07/11/17 13:49:06
>>285
ひょっとしてデバッグプリントっていうのはデバッガ使う、とか思ってるの？w

287:デフォルトの名無しさん
07/11/17 13:53:38
ファミコンにプリンタついてんの？

288:デフォルトの名無しさん
07/11/17 13:54:06
>>286
逆でしょ。組み込み云々の話をしているのに「デバッガがぬるい」とか「デバッグプリント」とか言ってる>282がすっとこどっこいなんでしょ。

289:デフォルトの名無しさん
07/11/17 14:29:33
>>287
ファミコンと同世代のSEGA SC-3000には4色プロッタプリンタがオプションであった

290:デフォルトの名無しさん
07/11/17 21:27:36
ある程度当てがついている状態でデバッグプリントが使えるなら、デバッガはいらんな。

291:デフォルトの名無しさん
07/11/19 13:47:48
よくわからんがおまえらが凄腕であることはわかった。

292:デフォルトの名無しさん
07/11/19 23:25:36
凄腕？んなわけない。ただの化石だろ。

293:デフォルトの名無しさん
07/11/19 23:39:25
そんなのおそまつ君の出っ歯だろ当然

294:デフォルトの名無しさん
07/11/20 09:13:55
プログラムにデバッグ用のコード埋め込むと、タイミングとかズレて虫捕りできないケースもあるんだよ。
かといって、インサーキットエミュレータがタイミングバッチリかと言えば、別の意味でタイミングがズレたりするんだなこれが。

295:デフォルトの名無しさん
07/11/20 13:59:53
デバッグプリントのせいでスタックの状態が変わったりするしな。

296:デフォルトの名無しさん
07/11/21 03:00:20
そういえば、昔は遠藤雅信氏が、２ちゃんに書き込みしてたよなあ。
このスレに、召還されないかなあ。。。？

297:デフォルトの名無しさん
07/11/21 22:18:23
自営業だったらすぐに召喚できるんだけどなぁ…

298:デフォルトの名無しさん
07/11/21 23:39:55
>>287
毛糸の絡み具合を操作することでグラフィック
を出力する、プリンタ的なものならあった。

299:デフォルトの名無しさん
07/11/23 01:35:12
>>270
純正機材は値段が言い値のぼったなだけで性能は全然大したこと無いだろ。
スペックコスト比で言えば当時の10万程度のPCと変わらん。

300:デフォルトの名無しさん
07/11/23 01:39:19
なんか知ったかぶりな人が来ましたよ

301:デフォルトの名無しさん
07/11/23 12:19:43
当時、10万+程度で買えるPCなんて存在しなかったのだが。

302:デフォルトの名無しさん
07/11/23 12:26:26
appleII+Romライタでやってたのかとおもったっす

303:デフォルトの名無しさん
07/11/23 12:47:51
>>301
90年代の前半とか、エントリーマシンでも、4,50万してたな。
そういえば。

304:デフォルトの名無しさん
07/11/23 13:52:42
>>301
言いたいことの意味は分かるが、言葉尻だけについて言えば
んなことはない。

305:デフォルトの名無しさん
07/11/23 14:39:26
MSX？アレはゲーム専用機だろ？

306:デフォルトの名無しさん
07/11/23 15:56:43
>>299がバカなのは「純正機材」と言う単語を意味も分からずに使っているところ

307:デフォルトの名無しさん
07/11/24 11:00:42
TreeViewとListViewにｘVN_GETDISPINFO相当の機能がなかったので、
Controlから派生させて自作したよ('A`)
（VirtualModeもパフォーマンスがよくなかった・・・）

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

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

・・・そんな感じだ。

308:デフォルトの名無しさん
07/11/24 11:01:57
>>308
誤爆ｽﾏｿ

309:デフォルトの名無しさん
07/11/25 18:05:03
ファミコンで一番最初に発売された「スーパーマリオブラザーズ」って
アセンブリ言語で作成されているの？
プログラムサイズが40KBとか聞いたのだが・・・

310:デフォルトの名無しさん
07/11/25 21:01:25
256kbじゃなかった？
っていうか、わざわざCとか使う理由がないでしょ。
アセンブラが難しいとか思ってるのならそれは誤解だよ。
いろいろ面倒ってだけで、じつはCなんかよりずっと簡単。

311:デフォルトの名無しさん
07/11/25 23:13:21
ファミコン用のゲーム開発で使っているアセンブリ言語って

ldx #$0
ldy #$0

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

312:デフォルトの名無しさん
07/11/25 23:17:25
プログラムサイズ内に、データを一切含んでいなければね。
通常、どんなプログラムにもデータ領域は含まれているわけで。

313:デフォルトの名無しさん
07/11/26 00:28:07
マップやサウンドのデータがほとんどでしょ
つーかマリオの頃ってまだバンクとかなくて最高32KBだったんじゃ

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

315:デフォルトの名無しさん
07/11/26 01:35:30
色はカラーパレットの変更だけだし、
（カラーパレットとは1という番号で示される色が実際何色かというデータのこと）
画像重ね合わせも、透明色があるから普通に描画するだけ。

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

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

317:デフォルトの名無しさん
07/11/26 06:24:11
>>301
AmigaとかAT&Tとかじゃないんだから

318:デフォルトの名無しさん
07/11/26 12:04:02
大昔コナミのグラディウスとイースⅠⅡを解析したことがあるけど、マクロアセンブラ程度
タイマー割り込み処理によるイベントドリブンなプログラミング手法はすごく参考になった。

319:デフォルトの名無しさん
07/11/26 16:54:54
>>301
十万円台で、ってことならPC-8001とかMZ-80Kシリーズとかあったね。
十万円ちょっとだと FM-7、十万円以下だと PC-6001、VIC-1001 (Commodore 64) とかか。

結構売れてた。

320:デフォルトの名無しさん
07/11/26 17:18:23
>>319
開発をFDじゃなくてカセットテープでやるの？
クロスアセンブラ（除くVIC）動くの？つーかあるの？

321:デフォルトの名無しさん
07/11/26 17:22:01
何言ってるんだ、クロスアセンブラなんて、ちょちょいのぱーだろ。

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

322:デフォルトの名無しさん
07/11/26 17:31:43
> クロスアセンブラの出力するバイナリをSフォーマットに変換した記憶がある。

それがどぅしたｗｗｗ

323:デフォルトの名無しさん
07/11/26 18:29:47
PC-8001 (or PC-8001mkII)　で CP/M なら確かクロス環境はほぼ揃ってたと思う。
ディスクユニットにせよソフトにせよ PC 本体並に高かったけど。

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

324:デフォルトの名無しさん
07/11/26 23:58:46
純正機材の中身は当時10万のPC程度
↓
当時10万のPCなんて存在しねぇ
↓
PC-8001とかMZ-80KシリーズとかFM-7とかPC-6001とかVIC-1001とか

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

325:デフォルトの名無しさん
07/11/27 00:08:15
>>324
いや悪いけどさすがにそれは君の読解力の方の問題だと思うぞw
ここ（に限らないが。。）は一人の人間が語ってる場所じゃないんだから
話題は複数同時展開することもあるでしょ。

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

326:デフォルトの名無しさん
07/11/27 00:30:56
何言ってるんだ、お前ら？

327:デフォルトの名無しさん
07/11/30 21:01:10
このスレは年齢層が高い。
明らかに三十路の壁を越えている

328:デフォルトの名無しさん
07/11/30 21:47:33
４０超えてんだろ。

329:デフォルトの名無しさん
07/11/30 22:21:58
ファミコン当時のアセンブラの話題とかリアルタイムで知っているとしたら30代後半でギリギリだな

330:デフォルトの名無しさん
07/11/30 23:15:05
エラーインクルードファイルがオープンできないとはどういうことか教えてください。
お願いします。

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

332:デフォルトの名無しさん
07/12/02 16:19:17
URLﾘﾝｸ(en.wikibooks.org)

333:デフォルトの名無しさん
07/12/02 16:33:14
コピペ君って馬鹿だな、まで読んだ。

334:デフォルトの名無しさん
07/12/02 16:41:06
>>332
ありがとうございます。
英語なので解読に時間が掛かりそうですが・・・

335:デフォルトの名無しさん
07/12/04 22:33:31
ファミコン開発にPC9801使ってた奴らはみんなモグリだろ。
任天堂が当時サポートしてた機種は富士通のじゃなかったっけ？

336:デフォルトの名無しさん
07/12/04 23:19:49
よくも知らない業界のことを適当な知識で話すな

337:デフォルトの名無しさん
07/12/07 11:41:25
開発機材はシャープ＆ハドソンの黄金コンビだった気が。

338:デフォルトの名無しさん
07/12/07 12:20:20
任天堂がまだただの花札屋だった頃、富士通にファミコンの共同開発を持ちかけたが
富士通は鼻で笑って相手にしなかった

富士通はないよ

339:デフォルトの名無しさん
07/12/08 06:34:53
不治痛・・・

340:デフォルトの名無しさん
07/12/08 12:32:40
オレがファミコンの開発をやったときはたしか富士通だったけど。

341:デフォルトの名無しさん
07/12/08 21:58:26
強制購入させられるのはHP製のICE

342:デフォルトの名無しさん
07/12/09 21:24:40
ファミコンソフトの開発って、スタートラインに立つまでにどのぐらいの投資が必要だったの？
>>335以降を見るとまちまちな回答が戻ってきそうな予感もするけどｗ

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

344:デフォルトの名無しさん
07/12/14 06:44:19
6502のICEに置き換えると、画面や音をどうやってたわけ？
それが不要なら単に6502の評価ボードでいいじゃない。

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

345:デフォルトの名無しさん
07/12/14 08:14:40
ICEってなんだか分かってる？

346:デフォルトの名無しさん
07/12/14 09:17:17
インサーキットエミュレータ　の事だろ？　CPUの場合は、その機能をプローブ側と置き換えてしまうわけだ
でも CPUの停止って出来たっけ？　それが出来るならICE使えるだろうけど

347:デフォルトの名無しさん
07/12/14 10:44:57
普通、ICEプローブはCPUを引っこ抜いてから挿すもんなんだが。

348:デフォルトの名無しさん
07/12/14 11:18:11
ファミコンのCPUはサウンド機能と一緒に同一パッケージ内に入ってるわけで、
そのＣＰＵを引っこ抜いてしまうなら、サウンド機能も入ってないといけない。

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

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

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

350:デフォルトの名無しさん
07/12/22 11:37:36
ＣＰＵと同じチップに入ってるのであって、ＣＰＵに乗ってるとは誰も書いてないぞ？

351:デフォルトの名無しさん
07/12/22 13:09:25
デシマルモードは確かに削られてるけど、間接アドレッシングとかは全部そのままなんだが。

352:デフォルトの名無しさん
07/12/24 13:09:17
ファミコンのCPUっていったら、普通2A03でいいんじゃないの?
音源も載ってるじゃん。

353:デフォルトの名無しさん
08/02/12 00:44:02
>>347
あるよ。
以上。
↓次どうぞ

354:デフォルトの名無しさん
08/05/31 08:24:29
保守

355:君はＭかい？　いや、第三者（物語作者）視点Ｓ。
08/06/11 06:37:03
ほとんどの話についていけないが
正直『初期』ウィザードリィは、無理。
スタート地点、今でいう地下何階だと
…たぶんポルナレフＡＡ推奨状況だよ。

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

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

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

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

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

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

357:デフォルトの名無しさん
08/06/18 09:04:16
その歳でその文章とはかわいそうに・・・

358:デフォルトの名無しさん
08/08/12 04:14:08
age

359:中 ◆yQK.F.Y.S.
08/08/12 10:21:22
ｌ

360:中 ◆clCGktrNww
08/08/12 10:23:10
ｐ；

361:中 ◆GlBYEEEEEE
08/08/12 10:24:30
；

362:中 ◆a/4.R5cvj2
08/08/12 10:26:22
；

363:デフォルトの名無しさん
08/08/12 18:28:31
色々な言語で書いても結局は機械語に翻訳されるんだろ？

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

364:デフォルトの名無しさん
08/08/12 22:43:53
早くはないな…。

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

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

365:デフォルトの名無しさん
08/08/12 23:07:21
ファミコン現役当時のゲーム前提なら、比較対象をCとして考えると
アセンブラを覚えた方がずっと早いだろうね。

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

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

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

366:デフォルトの名無しさん
08/08/13 00:05:00
AppleII に使われてたんだから有ったんじゃない？

367:デフォルトの名無しさん
08/08/13 01:54:38
>>364-365
お前知ったかぶりの王様だなｗ

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

369:デフォルトの名無しさん
08/08/13 11:46:27
・当時は手ごろなクロス開発環境がなかった。
・当時は適当な性能のコンパクトなコードを出すCコンパイラがなかった。
・当時は作らせる側の知識がないから作るためのコストを掛けたがらなかった(今もかw)。

370:デフォルトの名無しさん
08/08/13 12:30:29
>>368
チミって人から「よくらからない切れ方をする奴だ」って言われるでしょ？w

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

371:デフォルトの名無しさん
08/08/13 12:38:56
というかさあ、こんなスレにいるんだから大概40前後のオッサンが多いはずだと
思うんだが、いい歳こいてわけのわからない絡みかたするなよな。
近頃本当大人になりきれない「とっちゃん坊や」が多くて困るよ。

>>367とか>>368とか。

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

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

これ何か間違ってるか？

372:デフォルトの名無しさん
08/08/13 12:41:08
素直な疑問なんだけど仮に6502用のCコンパイラが
存在したとして、255文字を超える文字列はどう扱うのだろう？

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

373:デフォルトの名無しさん
08/08/13 12:46:27
ドラクエとかFFとかでそんな長い文字列はみたことないです（　＾ω＾）
文字も平仮名とカタカナと数字だけだったし。

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

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

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

375:デフォルトの名無しさん
08/08/13 13:27:06
>>371
おまえはいい年をして、まず馬鹿にしてからでないと議論もできないのか？

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

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

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

376:デフォルトの名無しさん
08/08/13 13:54:13
>>375
「できる・できない」じゃなくて「向いてない」って言ったんだよ。わかる？

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

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

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

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

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

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

378:デフォルトの名無しさん
08/08/13 14:04:15
互いに「相手は分かってない」という前提で、おっさん二人がそれぞれ一人喧嘩してるように見える。

379:デフォルトの名無しさん
08/08/13 14:12:54
あー読み返してみると上の文章じゃたぶん伝わらないなあ。。

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

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

380:デフォルトの名無しさん
08/08/13 14:16:36
>>376
お前＞ハードを叩くようなゲーム機ではＣは使いにくい（から、ファミコンではアセンブラだった）
オレ＞理由が違う。６５０２ではＣはムリだからアセンブラだっただけ。

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

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

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

381:デフォルトの名無しさん
08/08/13 14:26:44
何を勝手に誤解して勝手に熱くなってるんだろう。
まあそう熱くなりなさんな。

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

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

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

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

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

383:デフォルトの名無しさん
08/08/13 14:37:05
ど素人ねえw
当時のファミコンのコード書いていた人なら、まちがいなく俺の意見に
賛同すると思うけどね。

だって事実だからねえ。

384:デフォルトの名無しさん
08/08/13 14:38:47
ちなみに細かいようだがx68kじゃなくてX68kじゃないのか？
x86じゃないんだからさw
いやまあこれは言い掛りに近い突っ込みだとは俺も思うが。

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

386:デフォルトの名無しさん
08/08/13 14:43:52
ASCII誌だったかにGAMEコンパイラ載ってなかったっけ。
まあ昔のPC板向けの話題になるのであまり深入りは避けるが
そこそこ使えたような記憶がある(Apple][)

387:デフォルトの名無しさん
08/08/13 15:10:56
もしかして知ったかぶりの王様って言われたのが癪に障ったのか？
悪かった謝るよ、ゴメンゴメン

388:デフォルトの名無しさん
08/08/13 15:13:32
>>387
人間は自分の中にない物を人には言えないもの
お前が知ったかぶりの王様なんだろうが

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

390:デフォルトの名無しさん
08/08/13 21:13:08
スタックは256バイトあれば十分だろう。
スタックを大量に消費する方法で実装するのなら、それはする奴がアホなだけだし。

391:デフォルトの名無しさん
08/08/13 21:32:08
まあスタックもっと貧弱な8051やPICでもCコンパイラはちゃんとあるからね。

392:デフォルトの名無しさん
08/08/13 21:33:31
>>390
再帰とかスタック上に一時的に大きなオブジェクトを
取る事は全くないの？馬鹿なの？

393:デフォルトの名無しさん
08/08/13 21:38:14
>>392
当時のゲームで再帰とかないでしょ。
スタックにオブジェクトってそんなこと今だってしないでしょ。

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

394:デフォルトの名無しさん
08/08/13 21:46:33
まあ8ビットの時代は1バイトとの戦いだったから、今の
感覚で語ってもな・・・・

395:デフォルトの名無しさん
08/08/13 21:48:48
>>392
CPUやメモリのスペックを無視した設計をするあんたの方がよっぽど馬鹿なんだが

396:デフォルトの名無しさん
08/08/13 21:53:16
ファミコンソフトってHSPで作れますか？

397:デフォルトの名無しさん
08/08/13 22:52:39
>>388
ゴメンゴメンｗ

398:デフォルトの名無しさん
08/08/13 22:58:45
皆さんプライドがお高いようで

399:デフォルトの名無しさん
08/08/13 23:07:31
知ったかぶりの王様ｗｗ

400:デフォルトの名無しさん
08/08/17 00:03:00
ネオジオのゲームってアセンブリで開発されてたんだってさ。
それより前のファミコンなんかがアセンブリでもおかしくはないと思うが。

401:デフォルトの名無しさん
08/08/17 00:11:11
そりゃ、当時はなにで作られていたかって話ならアセンブラでしょ。

402:デフォルトの名無しさん
08/08/17 05:49:30
ネオジオはメインMPUが68000だからなぁ。
あの石は「アセンブリ言語は難解」ってのが全く当てはまらない。

403:デフォルトの名無しさん
08/08/17 16:50:23
6502だってそうだが。

404:デフォルトの名無しさん
08/08/17 18:49:09
あの石ｗｗｗ
アセンブリ言語は難解ｗｗｗｗｗｗ
メインMPUｗｗｗｗｗｗｗｗｗ

405:デフォルトの名無しさん
08/08/17 22:04:01
68000のアセンブリ言語は高級言語並に美しいからね。
6502はクセがありすぎて美しくない。

406:デフォルトの名無しさん
08/08/17 22:13:16
また知ったかぶりの王様か

407:デフォルトの名無しさん
08/08/17 22:37:03
両方つかった上での感想だが？

408:デフォルトの名無しさん
08/08/17 23:35:44
初代FCで初期にあった将棋ゲーのアルゴリズムが超早かったのが
今でも謎です。アセンブラでも早すぎて。

409:デフォルトの名無しさん
08/08/18 06:24:45
>>405ってCやC++も高級言語だと思ってるんだろうなぁｗ

410:デフォルトの名無しさん
08/08/18 13:47:45
>>405
6502自体に癖があるんだから当たり前。

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

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

412:デフォルトの名無しさん
08/08/18 19:28:05
おっさんクセースレだな

413:デフォルトの名無しさん
08/08/18 19:31:59
なんかいつの間にか68kの話になってる。

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

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

414:デフォルトの名無しさん
08/08/18 19:33:55
今の技術についていけないジジイどもの思い出スレ

415:デフォルトの名無しさん
08/08/18 19:38:18
ジジイつったってせいぜい40代だと思うぞw

416:デフォルトの名無しさん
08/08/18 19:47:59
今の技術 ^_^

417:デフォルトの名無しさん
08/08/18 20:26:30
>>409
普通は高級言語ですね。それ。

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

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

419:デフォルトの名無しさん
08/08/19 01:22:24
>>418
うるさい

420:デフォルトの名無しさん
08/08/19 07:14:53
>>418
１００点。
だがそれはあくまでも「アセンブラとしての美しさ」であり、それなら６５０２にもそれなりの
ポリシーがあり、６８０００は美しく６５０２は癖があるという主張の裏づけにはならないが、
そこの説明はどうする？

421:デフォルトの名無しさん
08/08/19 09:09:00
いわゆる16bitと8bitのMPUのアーキテクチャを比較して何がしたいんだこの人は？ｗ

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

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

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

423:デフォルトの名無しさん
08/08/19 09:41:48
結局また知ったかぶりの王様か

424:デフォルトの名無しさん
08/08/19 09:53:19
一行糞レス素敵ですね＾＾

425:デフォルトの名無しさん
08/08/19 09:58:19
>>422
無条件分岐命令が無いとか妄言書くなら
6502使ったことが無いなんて明白な事をわざわざ書く必要は無い

426:デフォルトの名無しさん
08/08/19 10:08:17
>>425
無条件相対分岐のBRA命令は無いよね。
絶対番地を指定するジャンプなJMP命令はあるけど。

427:デフォルトの名無しさん
08/08/19 10:37:34
PCエンジンのCPUにはBRAあるんだね。

428:デフォルトの名無しさん
08/08/19 10:46:24
>>422が言う「美しい」の定義を是非知りたいんだが（笑

429:デフォルトの名無しさん
08/08/19 10:56:35
>>427
6502から拡張された65C02をさらにカスタマイズしたチップだからね。
6502そのものではないよ。

430:デフォルトの名無しさん
08/08/19 10:59:34
6502は [zz],Y のアドレッシングモードがなかったら
これほど流行らなかったよな。

431:デフォルトの名無しさん
08/08/19 11:05:06
え？6502が流行った？

432:デフォルトの名無しさん
08/08/19 11:06:15
また無知の馬鹿が一人・・・・

433:デフォルトの名無しさん
08/08/19 12:49:22
6809>Z80>6502

434:デフォルトの名無しさん
08/08/19 13:17:27
6502ってApple][とPET2001とVIC1001と他にあったっけ？
とても流行ったとは．．．

435:デフォルトの名無しさん
08/08/19 15:34:21
Apple][が今のMacの礎になったんだが・・・・
まあ今もMacはPowerPCを捨ててx86になっちゃったけどね

436:デフォルトの名無しさん
08/08/19 15:42:39
>>433
性能ならこうだべ？
6809>6502>Z80

437:デフォルトの名無しさん
08/08/19 15:52:39
Macの礎はLisaじゃね
つかMacって68000だし6502関係ねーし

438:デフォルトの名無しさん
08/08/19 15:57:04
それを言うならPowerPCだって68000関係ねーだろ

439:デフォルトの名無しさん
08/08/19 16:20:45
↑お前バカだろｗ

440:デフォルトの名無しさん
08/08/19 16:26:45
設計思想がApple][とMacは正反対な気がする。

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

441:デフォルトの名無しさん
08/08/19 16:26:56
↑お前が馬鹿な事はよくわかった

442:デフォルトの名無しさん
08/08/19 16:30:10
もっと具体的に。
馬鹿というだけなら馬鹿でもできる。

443:デフォルトの名無しさん
08/08/19 20:32:52
>>422
ビッグエンディアンの利点って何だっけ？
なんか直感的には無茶苦茶不便そうだけどなあ。

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

444:デフォルトの名無しさん
08/08/20 00:40:11
ミドルエンディアンじゃなきゃどっちでもいいよ。

445:デフォルトの名無しさん
08/08/20 10:40:23
>>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

446:デフォルトの名無しさん
08/08/20 11:00:01
ゼロクリアされた領域に1オクテット単位で1を書き込んだのに
同じアドレスで2オクテット単位で読み出すと256が得られるのは
直感的な配置とは考えられない

447:デフォルトの名無しさん
08/08/20 11:09:44
> 人間にとって直感的で自然な配置であること

ｗｗｗ

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

448:デフォルトの名無しさん
08/08/20 13:39:52
…まあ、お前だけだ。

449:デフォルトの名無しさん
08/08/20 14:29:54
ビッグエンディアンだからネットワークに強いって何時の話？
68000の頃?

450:デフォルトの名無しさん
08/08/20 15:11:36
今のCPUはメモリよりCPUのクロックの方が数倍速いから
リトル点ディアンであってもtcp/ipに不利にはなってないよｗｗｗ

451:デフォルトの名無しさん
08/08/20 15:22:24
ネットワーク機器に使われてるCPUを知っての発言か？

452:デフォルトの名無しさん
08/08/20 16:06:45
PowerPCかARMでも使ってりゃいいよ組み込みは

453:デフォルトの名無しさん
08/08/20 16:17:37
ネットワーク機器だとMIPSとかPPCあたりが多い気がする。あとARMとかColdfireか?
PCIとか(S)ATAみたいなPC由来のやつらがリトルエンディアンなのはデメリットにならないの？

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

454:デフォルトの名無しさん
08/08/20 19:38:40
>>445
丁寧に説明してくれたのにケチつけるようで言いにくいけど、
やっぱり最下位の値がD4で最上位がD1とか直感的じゃない気がするよ。

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

455:デフォルトの名無しさん
08/08/20 23:43:39
>>454
ならないよ。両方やってきたけど、人間はどちらにも馴れることができると判っただけ。

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

457:デフォルトの名無しさん
08/08/21 00:03:06
しばらく68000使ってたけど別に慣れればリトルエンディアンでも
ビッグエンディアンでもどっちでもいいや

458:デフォルトの名無しさん
08/08/21 03:15:32
Interface9月号にColdFire基盤が付属してるから、使いにくいかどうか確かめてみれば？
フリースケールが第二回コンテストやってるし。

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

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

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

460:デフォルトの名無しさん
08/08/25 12:53:23
＞リトルはよくてビッグはダメって言い張ってる奴は、お寺の門の上に掛かってる看板見たいに、右から左に文字が書いてあったら読めないのか？
↓
＞リトルは読めるけどビッグだと本当にダメってなら、脳の障害を疑ったほうが良いぞ。

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

461:デフォルトの名無しさん
08/08/25 13:34:34
ていうか仮定が馬鹿丸出し。

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

462:デフォルトの名無しさん
08/08/25 16:55:19
>>459
ご高説に茶々を入れるようで申し訳ないが
「昔は、右から左に文字を書いていた」んじゃなくて、
あれは一行一文字の縦書きなんだよ・・・

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

463:デフォルトの名無しさん
08/08/25 17:14:50
敢えて茶々を入れるが、「一行一文字の縦書き」なんて知識なしにそう認識する奴はいないと思うよ。

464:デフォルトの名無しさん
08/08/25 17:25:11
ああ
日本語は縦書きが基本という予備知識は必要だな
横書きという概念自体輸入物だ

465:デフォルトの名無しさん
08/08/26 11:37:40
言語学板でやれ

466:デフォルトの名無しさん
08/08/29 06:11:11
PCエンジン版のツインビーなら仕事で作った事あるぜ

467:デフォルトの名無しさん
08/08/29 07:01:44
ツインビーで最も良いのは出たな！！とヤッホー！。
X68000版の出たな！！の移植度は賞賛に値する。

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

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

468:デフォルトの名無しさん
08/08/31 21:37:23
すぐ俺が俺が！になるから
ちょっと頭冷やして過疎ればいいよ

469:デフォルトの名無しさん
08/10/04 21:19:24
プログラムに触れていると
昔昔、ファミコンやスーファミ時代の記憶が蘇ってしまう。
ああ、今になってあの頃を思い出す事になるとはなぁ…

470:デフォルトの名無しさん
08/12/03 09:45:11
おにゃん子タウンとか
ファンキーモンキー西遊記とかあれ高度なプログラマーなの？

471:デフォルトの名無しさん
08/12/03 10:08:27
>>470
高度かどうかは兎も角、少なくとも“プログラマー”ではありません。

472:デフォルトの名無しさん
08/12/17 17:59:29
今来た。こんなスレあんだね。
元FCPGだけど覚えてる範囲で書き込んでみる。

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

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

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

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

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

長文スマソ

473:デフォルトの名無しさん
09/01/22 01:38:36
こんなスレがあるとは初めて知った。

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

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

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

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

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

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

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

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

次ページ