１フレームあたりの cpu.bus.gpu.ly == 144 のターンが多すぎるんじゃないでしょうか？ １フレームで１回の呼び出しになってないように思います。

17:50 画面表示

おぉ、ついに画面でましたね。 画面の色が反転してるので、たぶんパレットの定義が真逆になってますね。

やっぱり描画処理で正しく表示されたときの感動がありますよね。 おめでとうございます。

15:50 0x60 が 0x06 に変わっちゃってます

おぉ！？なんか出ましたね！（モノクロなはずがカラフルなドットが出ている‥）

5:40 021Cで止まっていますが、このアドレスの命令は「RET NC」です、条件に満たさない場合、今の実装ですとPCにバイト数が足されず、PCが変化しないので止まってしまいます。 （C NZ Z）も同様に条件に満たさない場合は止まってしまいます。

JR命令はJP命令の相対ジャンプ版みたいなものです。 この命令は現在のPCからオフセット符号付き8ビット（-128～127）を加えてジャンプできる命令になります。 　ジャンプ条件は5種類あって、「無条件 NZ Z NC C」です。 条件が成立した場合の、PCの値は、”現在のPCの値”に「”命令のバイト数”と”次のバイトを符号付き8ビットとして読んだもの”」を足します。 　「PC = PC + 2 + i8」 　ただし、実装では命令のバイト数は後から足される仕様なので、「PC = PC + i8」で良いです。 条件が不成立の場合は、PCには命令のバイト数だけを足します。

前回実装したRST命令は、CALLと同等なのでリターンアドレスをプッシュしておかなきゃいけないと思います。 それと、オーバーフローの心配をされてしますが、それに対処するのが wrapping_add (sub) なので、場合分けのコードは不要かと思います。 u16の場合、0x0000 に wrapping_sub(1) したら 0xFFFF になって、0xFFFF に wrapping_add(1) したら 0x0000 になります。

「テストロムの0xFF01についての説明」 0xFF01には、一文字ずつアスキーコード(8bit)が書かれます、なので一文字書かれる度にログに出力する必要があります。 従って、ログの処理はwrite_byteに書いた方が良いです。 例えば「cpu_instrs」という文字列をテストロムが出力する場合、 １、まず、”c”(文字コード：0x63) が0xFF01に書き込まれます。 ２、それをログで出力します、出力の際、0x63の後ろに終端文字0x00を付ける必要があります。{0x63 0x00}（終端文字がないと多分落ちます） 　残りの文字も同様に一文字ずつ書き込まれるので、同様にログに出力します。

JR命令も怪しいです　（未実装？）

26:00 ファミコンの方のソースを開いてますね。

このテストロムはPPU未実装でも使えるように、結果が0xFF01にアスキーコードで出力されるようです。

アドレス「066B」の命令は0x0200へジャンプする命令ですが。。そのまま「066E」に進んでるので、ジャンプできていないみたいです。

この後、別のエミュレーターを作る予定はありますか？

14:45 let addr = addr + ((bank - 1) * 0x4000) 本当か？ let addr = addr + ((bank - 1) + 0x4000) これじゃない？

0000h～0068h は RST命令や割込処理時の実行コードが書かれてます

パレットですが、ピクセルの2ビットをインデックスとして、0xFF47レジスタのパレットを使うみたいです。

背景は横256ドットなので以下のようにもできます。 256バイトの配列を用意して、横256ドット分をこの配列にいれる。 unsigned char line_buffer[256]; 画面に横160ドット分を描画するときに、この配列からデータを持ってくる。 配列のアドレスは「(PPU_SCX + i) & 0xFF」で計算。 　0xFFでANDすることで255を超えたら反対にループされます。 //PPU_SCXはFF43hのレジスタです。 for(int i = 0; i < 160 ; i++){ LCD[(LY * 160) + i] = line_buffer[(PPU_SCX + i) & 0xFF]; }

「Emulating the Gameboy.」で検索して出てくるページも参考になりそうです

動画内で見つけられなかったドキュメント、こちらですー github.com/akatsuki105/gb-docs-ja

4:43 この方のＧｉｔｈｕｂにドキュメントがありましたよ

let mask =1 << 7 -plexel_indexになってますがおそらくドキュメントでは括弧が付いてました。

どうせならBandai Playdiaのエミュレータを作って下さい。GBエミュはもうあるのでね

お大事にして下さい。

継承が非常に理解しにくい

Swift で、言うところのprotocol ってやつですかね

おれ、HyperCard世代な人なんですけど、SwiftUIで倉庫番、作ろうとしてる。 もし、これが出来たら、ドラクエ作れるなあって、気もする

18:00 INC r8 と INC (HL) ではゼロフラグは計算結果が０なら立ちます。 INC C のテストが通っちゃってるのがおかしいんですけど、今の実装では加算は16ビットで計算して、代入する時だけ8ビットにしているため、元の値が 0xFF のとき加算後の value が 0x100 になって、それを update_flags に渡しているのでゼロフラグが立たなくなってるものと思います。

11:00 wordだと、Aレジスタを読み書きする命令で問題が出そうです。オペコードの0xEAと0xFAです。

hogeを使うやつって基本的に気配りができない。 sampleと書けばhogeって何ですかと聞かれる可能性が0になるのに、そのことに気がついてない。

米軍のなんかの在庫が、どっかで使い切ったタイミングってことで(´・ω・`)

なんか、コマンドみたいなめっちゃ長い文の意味や説明、なにのことを書いてあるのかとかの動画って作れますか、？忙しいとかなら大丈夫です！ もう作ってあったらなんて調べたらでてくるか教えてください！

よくRustやJavascript系やＧｏ言語書いたりと言語をすぐに変れるの凄いです😃今すぐにJavascriptの関数の定義とかTypescriptのジェネリクスとかすぐに書けますか？笑　Rustではあまり見ないけどconstが基本ですよ？ｗ

z80(GBもたぶん)は内部の演算器が4ビットで、2回に分けて計算しているみたいです。 1回目：下位4ビット同士を計算します。 　5ビット目への桁上りがハーフキャリー 2回目：上位4ビット同士の計算をします、1回目での桁上りも考慮します。 　2回目の5ビット目への桁上りがキャリーフラグ 出力 = 1回目 | 2回目 << 4

ハーフキャリーを設定で、引く前の下位４ビットと、引いた後の下位４ビットを比べていますが、引く前の下位４ビットと引く数（DECなら１）の下位４ビットを比べないといけないと思います。 それと、indirect HL の update_flags の引数が違っているっぽいです。

少し前の実装ですが、ADC A, E とかのテストで、assert_eq! でＡレジスタの値をチェックすべきところで、Ａレジスタへの代入になってます。

ハーフキャリー（CP命令）　（SUB命令も同じです。） 足し算が引き算になって、0未満かの判定に変わっただけです。 half.carry = (left & 0x0F) - (right & 0x0F) < 0; SBC命令ではキャリーも引きます。 half.carry = (left & 0x0F) - (right & 0x0F) - carry < 0; 違いとしては、足し算か引き算か、キャリーも一緒に計算するか、判定が(x > 15)か(x < 0)の違いです。

12:09 8ビットレジスタのインデックスの並び的にAが最後の7番目なので、その並び順になります。

多分？ 新Aレジスタ = 旧Aレジスタ + ソース値 + キャリー; キャリーF = 新Aレジスタ & 0x100; //9ビット目が立っているか？ ハーフキャリーF = (旧Aレジスタ & 0x0F + ソース値 & 0x0F + キャリー) & 0x10; //5ビット目が立っているか?

12:03 オペランドを取ってくる処理の共通化について 何回か前の回のコメントで指摘されていましたけど、オペランドのレジスタとかは命令コードのビットパターンに埋め込まれています。 たとえば、今回の ADC のような８ビット演算命令はビット０〜２がそれです。 その３ビットを渡して source_value を返すような関数を作ればよいと思います。 今の実装では instruction は命令コードを持っていませんけど、ブログラムカウンタの場所に命令コードがあるので取ってくることはできそうです。

コメントしました（見えなかったら、新しい順にしてみてください、なぜか評価順だと表示されないので）

オペコード表に、誤りを発見しました。 1、「LD (C),A」と「LD A,(C)」の命令は2バイトになっていますが1バイトが正しいです。 2、「JP (HL)」は表記間違いで、正しくは「JP HL」となります。 単純にPC=HLするだけです。（HLが示す番地にジャンプ。） 3、CB系のSRA命令（0x28～0x2F）のフラグが「Z 0 0 0」となっていますが「Z 0 0 C」が正しいです。

外部拡張音源知らないのね。

インデックス値に対応する表はCPU Instruction Setの最初の方にあります

HLIとHLDですが、Iはインクリメント、Dはデクリメントを意味していて、ロード後にHLレジスタをインクリメントまたはデクリメントするという動作になります。

オペコードの0x40から0x7FのLD命令は多いように見えますが実はレジスタの組み合わせなので オペコードのbit0～bit2がロード元のインデックス値、bit3～bit5がロード先インデックス値になります。 ロード元とロード先のインデックス値が両方6のときはHALT命令になります。

ハーフキャリーフラグ 　x＝(value1 & 0x0F + value2 & 0x0F) & 0x10 キャリーフラグ 　x=(value1 & 0xFF + value2 & 0xFF) & 0x100 xがtrueならフラグがオンになります

タイトルからして、なんだか「臭う」タイトルなので、コメント欄を見てみると、やはり「臭った」通りの内容だったようで・・ せめてオブジェクト志向と関数志向の違いを具体的に示してくれと思う。 モデルの中にロジック放り込むようなオブジェクト指向はオブジェクト指向じゃないしね。

お客様 突然のご連絡失礼いたします。プロのAmazon販売者奈子と申します。 弊社は客様の『生活の質』の向上に一生懸命に努めるブランドです。 すべての製品が安全で安定していることを確実にするために、厳密なテストプロセスを実施しています。世界中に輸出されています。お客様の満足度は最優先です。 拝見したところ、お客様はRaspberry Pi・PCの電子機器に興味を持っています。 現在、弊社はRaspberry Pi 5キット用の新製品を発表した。25,000円以上の価値がある商品なので、Raspberry Pi 4GBキットの内容：Raspberry Pi 5 4GBボード*1(技適マーク付き)/アクティブクーラー*1/PD電源アダプター*1/64GB MicroSDカード/Pi 5用黒色ABSケース*1/Micro HDMIケーブル*2/ドライバー*1/カードリーダー*2など、豊富な付属品が含まれています。 この製品は非常にプロフェッショナルなものなので、プロフェッショナルの方々にAmazonレビューをお願いしたいと思います。もしよろしければ、弊社の製品を購入し、製品の使用感を書いてみませんか。もちろん、製品は無料で提供されます。 弊社の商品を日本に宣伝したいと思っておりますので、KZfaqで商品レビュー動画と提携関係を作りたいと思っております。KZfaqの動画とアマゾンでレビューできれば、製品は無料です！ 動画が撮れないなら場合は、ブログの日記とアマゾンでレビューできればも良かったですね.ブログ記事とアマゾンレビューを書くことに興味があれば、製品は無料です！ ご興味がありましたら、ぜひこちら[email protected]連絡してください！ なお、ご不明な点がございましたら、ご要望に応じて、提携の形をご相談いたします。 ご返事頂ければ幸いです、よろしくお願い申し上げます。 早川 奈子