ファミコンのプログラム４
ファミコンのプログラム
http://pc8.2ch.sc/test/read.cgi/gamedev/1013696305/
ファミコンのプログラム２
http://pc11.2ch.sc/test/read.cgi/gamedev/1135099156/
ファミコンのプログラム３
http://toro.2ch.sc/test/read.cgi/gamedev/1214210285/
■関連サイト
MagicKit Homepage
http://www.magicengine.com/mkit/
すずめ愛好会
http://web.archive.org/web/*/http://vsync.org/ns/index.html
ｷﾞｺ猫でもわかるファミコンプログラミング
http://gikofami.fc2web.com/
わいわいの巣
http://www.geocities.jp/yy_6502/
mck hogehoge
http://takamatsu.cool.ne.jp/dutycycle/
NES info, programs, and demos
http://nesdev.parodius.com/
pgate1@crystal
http://crystal.freespace.jp/pgate1/
cc65 @ wiki
http://www34.atwiki.jp/cc65/
NES Hack Factory
http://www.geocities.jp/kz_s6502/
D-Soft
http://aqube.kir.jp/dsoft/index.html
OBONO's Web Site
http://homepage3.nifty.com/obono/
Family Assembler
http://fuguri23.hp.infoseek.co.jp/FamAsm/
nurvle.com(NES)
http://www.ash.ne.jp/~nurv/nes/
peacemay.net
http://peacemay.net/
ファミコンソフト開発のおへあ
http://stargate.game-server.cc/fc/
第７サプライヤー
http://seventhxevo.xxxxxxxx.jp/seventh/
ディスクシステムのタイマー割り込み利用してたんだね
１だと0爆弾だったのに
なんかどのサイトにも
ディスクシステムのIRQタイマに関する記述があまりないんだよね・・・
どのアドレスを使うかはわかってんだけど
1カウントが何秒位なのかの載ってるとこがない・・・
自分で測った感じだと
カウンタに65535(MAX)を設定してみたところ
11フレーム中に5回割り込みが発生した
1回の割り込み毎に2.2フレームであるから
1/60*2.2=0.036666･･･秒、つまり
65,535カウント≒36,666,667n秒 よって
1カウント≒560n秒位
スーパーマリオUSAか？
NESのマリオ２か？
でも>>3の計算だと少し精度が甘いからラスタスクロールとか使うときは
NMIが起きるごとに再設定した方が確実だろうね
それからRAMアダプタに入ってる水晶は21.47727MHｚだったから
21,477,270*0.00000056≒12
つまり12分周されたクロックが入ってるっぽい
(つまりファミコンのMPUと同じ1.79MHz)
あとタイマーへのクロックを何分周するか変えられないのだろうか
$4022になにか知らないオプションもありそうな気がしてならない
そういえばそんなのあったな
すまんボケまくったｗ
ディスクシステムなら日本人エミュ作者のがいい
CPUのクロックは12分周が基本だから
それ以上でもそれ以下でもメリットは無いでしょ
>それ以上でもそれ以下でもメリットは無いでしょ
まあそうなんだけどね
何クロックと考えた方が良い。1h=約113.7クロック
PPUアドレス空間にアクセスできないようにしたんだろうね・・・
やはりコストからか
画面表示が引きずられちゃう
なかなかない気がする
あの頃のPCだとほとんど同じような感じだったと思うけどな
MSXとか感覚的にはファミコンとほぼ同じというかもっと簡単だけど
あの頃は個人レベルでハードウェアの隅々まで理解できる環境が多かったな
上は縦スクロール、下は固定(「沙羅曼蛇」のような画面)に挑戦しています
0番スプライトを画面左端に持ってきて、左端8ピクセルを$2001で隠すと
$2002のヒット検出はできないでしょうか
ためしにやった所
G-NES：できる ＶｉｒｔｕａNES：できる
実機(AV仕様)：できていない(下画面が描画されない。左端クリップ無ければできる)
おそらく実機PPUの仕様かと想像しています。
やるってことじゃだめなのか？
実機でできないなら、できないものなんだろ
0spriteを1dotだけのものにするとか、回避策はいろいろあるだろう
・クリップ領域から出るように、左から9ピクセル目に仕掛ける
・1つ前のラインの右端に仕掛ける。
のどちらかで出来ると思うんだけど。
クリップ領域に0爆弾置いたら不発になるのは、0爆弾はスプライトを表示するタイミングに依存してるからでないの。
つまり、クリップした区間ではスプライトの表示処理自体がスキップされるとかそういう理由で。
俺、0爆弾なんて使わないから想像なんで違ってたらすまんが。
HBlank中に掛かるように右端でやれよ
背景ピクセルの上に0番スプライトのピクセルを重ねて、ピクセルを描画。
→ このとき、描画したピクセルが透明色でなければ、
$2002の[6]番目のビットが立つ。
→ このとき、描画したピクセルが透明色ならば、
$2002の[6]番目のビットは立たない。
って感じじゃなかったっけ？
クリップで強制的に透明色にされた背景ピクセル＋強制的に透明色にされた透明スプライト＝透明色
なので、0爆弾がヒットしないんじゃないかと。
実機もないし、エミュで試してもいないので、想像ですまん。
てか、過疎っぽく見えて、読んでる人いるんですねｗ
やっぱり0スプライトを左端、というのは
いい方法じゃないですね
右端に置くとか、IRQ割り込みとかでやってみます
0番スプライトでやるとなると、BGもひと工夫が必要ですね
ヒット検出しないのが正解だろうね。 実機でそうなったんだし。
上から覆い隠してる訳ではなくキャラクタを表示していない（と俺は考えてる）のだから、ヒットしなくて当然と思うけど。
左端がダメとかは、関係ない。横スクロールの指定はいつでもできる。
次のラインまで最低でも12クロックはズレたままでしょ
ライン単位での描画しかサポートされてないエミュだと再現できないけど
>>20 はどちらかというと間違い HBlank中が必須というわけではない
>>24 のようにCPUがフェッチ＆デコード＆実行＆ライトやってる時間にも、PPUのドットは結構動くことに注意
普段はG-NESの使いやすいデバッガでデバッグ。
使いやすいVirtuaNESやNNNesterJでおおまかな確認。
際どいタイミングが必要なデバッグはFCEUXとNintendulator。
Nestopiaでタイミングの最終動作確認。
右端なら画面に影響は出ないわな
現実的な問題がな
最初のうちはなれていたけど
CとかC++とかASに触れていくにつれて
面倒になっていったな・・・
あぁそれはありますよね…。感覚というか形態が違いますからね…アセンブラは
最初のうちは高級言語のクラスとかオブジェクト指向とか全く理解できなくて、
アセンブラ至上主義で6502とか8080とか8086とかいろいろ手を出してたんだけどね・・・
6502向けのCコンパイラとかいいのないよね
てかそもそも8bitCPUに高級言語使うのもおかしな話だけどさ
某C言語が使えたポケコンは、全然速くなかったよ
さすがにBASICよりは速かったけど・・・
Z80なら需要があって割とあるけど
最適化があまりうまくないけどな。
素人レベルだと十分だわ。
C言語だけでリアルタイム処理なゲームを作って動かせる、それを配布できるってことは、今で考えるよりもずっと贅沢な事。
個人ユーザ中心のホビー分野ではそれなりに需要あったんだろうけど。
それとFDみたいに安いメディアかつ少数生産で済む16bit世代なPCゲーとか。
8bit機だと非力すぎる上にどうせ機種依存バリバリな処理系しかないからCで書いても他で流用のしようがない。
使うことにデメリットは多くても、メリットになる部分が全くと言っていいほど無い。
メガドラは時期的に言ってアセンブリ言語手書きだと思われる。
人間が手書きしても全然苦にならない整然としたアーキテクチャだったし、セガが発売したゲームがどれもROM容量ケチってるあたり、C言語使って容量無駄に使うことが許されたとは思えない。
当時は、ハードメーカーから提供されているのが
アセンブラだけとかだったからだろう。
プログラムといえば、BASICかアセンブラという時代なんだから、
c言語がなくてもしょうがない
なぜC厨が湧く
http://kohada.2ch.sc/test/read.cgi/gameurawaza/1345225953/908-909
必要ならコピペでもなんでもどうぞ
よく言われるように16k毎にベクターやリセットルーチンとかを設置する必要はなく、
32k毎の設置で一切問題はなかったので、リセットで偶数バンクが後半16kにあてがわれることはない模様
ファイナルファンタジーや三國志とかを見ると最終バンク以外にリセット等のベクタを置いていないから
バンクサイズ16kで後半最終バンクFIXモードだと不定になることはなさそうな感じ
無印のMMC1が手元になく確認していないのでひょっとしたら仕様変更があったのかもしれないけど
それとbit7立ててバンクの初期化って古いエミュだと実装されていないから
GNESとかVirtuaNES使ってると理解できないのはしかたがないと思う
でも動作保障とかめんどいからキット販売がせいぜいか。
pcエンジンエミュレータ「MagicEngine」の作者が作ったものを
バージョンアップしたコンパイラHuC
http://www.zeograd.com/
HuC使ったけどすごく重いです
stgを作ろうとしたんだけれど
タスクを自機弾10、敵3、敵がばらまき弾8方向くらいで処理オチしてやる気無くなた
この程度のゲーム30fps20fpsにする意味無いし
エミュもリアル本体並み程度の能力しかないから処理落ちします
処理落ちしても良いアドベンチャーならまだしも
日本語表示の壁が
最大容量もPCEは2メガバイトが限界
古いHuCは多少軽いし、マジックエンジンHPからダウンロードできますが
機能が足りないです
http://www.youtube.com/watch?v=-J0H5ah1G7A
これ内蔵音源のみってマジかよ
ttp://www.youtube.com/watch?v=4_gObHt1uZA
そういう方向に進化せざるをえなかったのかな
主人公キャラクタがオブジェに隠れる演出はすごいよ〜
キャラと重なるBGオブジェを、重なっているときだけスプライトにしてるのかと思ってた…。
でも素直にそうやっちまうと、スプライト用のパレットが足りなくなるのね。
ほんと凄まじい発想だわ…
もっと派手な演出なら、既出だろうがRareのBattletoadsも良いな。
https://www.youtube.com/watch?v=-1UwbUencb4
しっかりした2重スクロールは、PCエンジン以降でしか見たことない気がする。
スプライトモード8x16の時、普通指定するのとは逆のキャラ番号(偶数なら奇数、
奇数なら偶数)を指定すると、BGバンクのキャラがスプライトで出ます。
また、このBGバンクのスプライトを他の表示するスプライトよりも優先度を上げ、
BGより優先度を下にすると、他のスプライトはこのスプライトより下、つまり
BGより下に表示されます。
BGより下に表示されるのでパレットコストは必要ありません。
これを効果的に使えば細かいマスク処理が出来るはず。
横並びが厳しいので使い所は限られると思いますが…。
自分もソルスティスはコレを使ってるのかと思ってたんですが違いましたね。
何か問題があるのか、単にこの方法を知らなかったからなのかは分かりませんが。
PCエンジンでは使われてたらしいけど、ファミコンでこの方法を使ってるゲームはあるのかな？
http://www.dotup.org/uploda/www.dotup.org3771924.png
上にスプライトで表示してるのを4枚、下の同じキャラの岩の所にも
BGより優先度下にして表示してあります。
シルバーホークがBGの地形より下、BGのボスより上に表示されてます。
柱に隠れる演出とかにも使えるかと。
スプライトの優先度とBGの前後の関係は、まずスプライト番号の若いものが最優勢され、
1番目のsprがbgの裏、2番目がbgの表だったら、2番のsprは1番に重なる部分は1番に消されて、表示されない。
1番sprからはみ出た部分だけがBGの表に見える。
がんばれゴエモン外伝のオープニングで、えびす丸がドアから出るシーン、スプライト優先度をうまく使ってる。
いまどきダライアスとか言ってるのってリタイアしたキチガイ互助会の方なのかな
結局BGをスプライトにしてるから、VRAMの余裕はできても、
スプライトパレットの余裕はできないんじゃね？
CHR-RAMは極めるとすごいな。
弱点としては、VBLANK時に1フレームあたり
10キャラくらいしかロードできないんだっけ。
扱い方が難しいところも燃えるなぁ。
ソルスティスの技術。上位オブジェクトの重なりと非描画判定は凄い。
後にラグランジュポイントはCHR-RAMって8KBなんかな。あのパターン
量を見ると8KBではなさそう。
セリフ用の文字画像部分を足して16KB搭載かつセリフウィンドウ部分
で割り込みバンク切り替えしているんじゃないかと推測しとるんだけど。
それともただのCHR-RAMなのだろうか。
ラグランジュポイント、CHR-RAMの実体は8K
ttp://bootgod.dyndns.org:7777/profile.php?id=3643
ただし、参照配置換え可能。
普通のCHR-RAMならBGを4K、SPRを4Kと固定で、$0000か$1000に配置するけど、
参照配置換え可能ならばBG、SPRそれぞれ0〜8Kまで1K(page)単位で柔軟なサイズ変更が出来る。
割り込みかけて途中で参照を変える、と。
SPR：BG = 1：7〜3：5、位じゃないのかな。
あ り え な い 。それは。
バストダンジョンでリリカのおっぱい値を８００近くまで調教強化してやらないと、そのフラグは立たない。
仮にフィリオナをメンバーから外してリリカを集中調教しても、アナルバイブが使えないその段階では
スカリバーはまだ手に入れられないはず。 妄 想 で つ か ？
とりあえずアンダー草原で淫獣マリリスを大量に調教して淫度をどんどん稼いどけ。
展開が不安ならバックアップ取っておくのを忘れんなよ。説教くさくなってスマソ・・・。ついな・・・。
RAMのバンク切り替えの様なもの、というかメモリ参照の位置が変更
できるなんて想像の斜め上を行っていたとは・・。驚きました。
63の書き込みを見て調べた結果に驚きました。
ROMを乗せるはずのところに、一工夫してRAMを乗せるとこうなるのですね。
( ；∀；)ｲｲﾊﾅｼﾀﾞﾅｰ
誰か何のことか分かる人いる？
今調べてるんだけど出てこない・・・
http://wiki.nesdev.com/w/index.php/File:Apu_address.jpg
矩形波とか三角波とか、現在の値が見れるっぽいね
でも、実用上ほぼ全く役に立たなそうだな。
有益な情報をありがとう
ファミコンのプログラムはもうずっと前からしてるがこれははじめて知った・・・
これらを使用していたソフトが無いから、任天堂からの資料にも書いて
いなかったんだと思う
使いどころを考えてみたら、DPCMのを鳴らす前のプチノイズが出ない
ようにしたり出来るかもって位かなあ？
http://wiki.nesdev.com/w/index.php/CPU_pin_out_and_signal_description
TSTピン(30番ピン)をプルアップにしないとダメなのかな？
試せる人いたらタノム
やっぱり
NesDev界隈には回路の写真から解析しちゃう人いるんだな
色付きの線で実に説明上手だ
祭りだﾜｼｮｰｲ
>>80
オープンバスって「レジスタに繋がってないただのアドレス」
という意味でいい？
ファミコン用のCライクな言語のコンパイラを作っていて、
とりあえずnesasm向けのasmを出力してるんだけど、
リンクとか考えるとcc65のアセンブラのほうが高機能っぽいので現在迷い中・・・
このスレにCは需要無い
Cでやるならcc65のCを使うでしょ
x86のCコンパイラが吐く自動変数っぽい仕組みのを
nesasmで書けるマクロ組んでみたけど
遅くて使い物にならなかった
自分が見た範囲だとnesasm使ってる人が多そうだけど、それ以外にもメジャーなアセンブラがあって、
そっちのほうが便利だったら乗り換えたいなというくらいの気持ち。
nesasmは、リンク機能がないのが直近の不満なんでそれ書いた。
> 遅くて使い物にならなかった
cc65が出力するasmを見て、このままだと遅すぎて使えないってのは同意。
工夫すれば実用的（アセンブラの1/2くらい？）にはなりそうなのでちょっと作ってみてるというところ。
といっても、割り込みや速度が必要なコードはasmで書かないとだめなのは諦めてる。
> このスレにCは需要無い
高級言語の需要はなさそうだなぁというのはわかってて、そういうの作ってるっていうのを書いたのは、
もしかしたら興味あるひとがいたらいいな、という下心はすこしありましたｗ
2013年1月25日、48時間でゲーム作れやぁという世界規模のイベント
global game jamが日本で開催された。
様々な作品が発表される中、札幌会場では、何とファミコンのゲームも
開発されたという。それが、これ。
ttp://globalgamejam.org/2013/famicom-nes-regeneration-project
小規模の作品ではあるがしっかりと動く模様だ。開発はハンドアセンブラ
で製作、というから驚きである。48時間の多くは、ファミコンの仕様調査に
費やされたとのこと。なんとも変態的な情熱である。
libファイルを組み込んで鳴らしい。使い方はまったく解らん。内部構造
とかは詳しく解説してはあるヘルプが付いてるけどね。ちなみに、これ
用のmmlコンパイラも付属しているよ。
ttp://shaw.la.coocan.jp/nsdl/
すごい．
なによりも，この開発者さんの情熱が凄い．
ぜひ使わせてもらおう．
のデータを見ること出来る？スーパーマリオで土管に乗るとかPPUのデータ
から判定してるかな？まさかCPUのRAM0x0000-0x07ffに入れてそれを見てる
ってことはないよね？
デュアルポートRAMなんてなかったし
VRAMのデータで当たり判定してたはず
画像ハックすると永久落下とか？
こんなのは例外で
スーパーマリオなど普通はCPU空間のRAMに仮想地形を作る
>VRAMのデータで当たり判定してたはず
>画像ハックすると永久落下とか？
自機の移動先座標のドット色情報で当たり判定してたベーマガの投稿プログラムを思い出した
100〜のスレッドの続きを読む
