CopyNES のしくみ

Welcome! - retroUSBでUSB CopyNESを購入した。
CopyNESとは、NESのカートリッジをコピーする装置です。NESのCPUを取り外して、CopyNESの基板を取り付けることで、PCからNESをコントロールできるようになります。PCからNESを制御することで、カートリッジを読み出します。
動作原理はリモートデバッガと同じなので、リモートデバッガを勉強するのに良い素材だと思う。

http://www.retrousb.com/products_pictures/usbcopynesbig.jpg
CopyNESのしくみを理解するために、http://tripoint.org/kevtris/Projects/copynes/tech.htmlの内容を軽くまとめてみた。

CopyNESの動作概要

CopyNESのブート時の動作

  • 電源起動時に、カートリッジのROMを無効にし、CopyNESのROMを読み込ませる。
  • CopyNESのROMを1000-1FFF, 3000-3FFFにマップする。
  • 割り込みベクタのジャンプ先を、CopyNESの領域に変更する。
  • カートリッジのROMを通常の領域である8000-FFFFにマップする。

CopyNESのモード

  • play mode 普通にゲームが動くモード
  • copy mode パラレルポートからの指示を待つモード

CopyNESの部品

  • 74157 A12-15のアドレス線セレクタ
  • 74138 CopyNESのEEPROMと6522用のアドレスデコーダ
  • 6522 6502用のUART通信チップ PCとの通信用
  • 27C64 64kbit EEPROM (8Kバイト)

CopyNESのソフトウェア

  • ホスト側のコードはQBASICで作成(その後Visual Cに移植)
  • NES用のコードは6502アセンブラで作成
  • プラグイン機能で各種マッパーに対応
  • カートリッジから読み出したデータは.NESファイルとして保存する。

オプション

  • RAM Cart
    • 32K/8K
    • RAMにデータをダウンロードすることで、ゲームを実行可能
  • NSF Cart
    • 128K
    • RAMにNSFデータをダウンロードすることで、NSFが再生できる

うーん、やっぱりコードを読まないと良くわからない部分が多い。理解するために、CopyNESをエミュレータで動かすというのも素敵な気がする。


USB CopyNESは、ファミコンに取り付けることを考えています。だけど、ファミコンにUSB CopyNESを取り付ける場合には、ファミコンをケースから出さないとだめだし、さらにリセットスイッチが干渉するので、外さないと基板が乗っからない。

ebayのRSS

ebayのRSSが、2008年の後半から普通の手段で取得できなくなっています。
なので、個人的に調べたebayのfeedのURLを紹介します。

検索結果のフィード

次のURLにstatitle=の部分にキーワードを入れれば検索結果のフィードが取得できるよ。

例:PSP

ストアのフィード

例：Select Classic Car Parts and Gifts
みんなで、散財しましょう。

IEEE 802.11r について　シーケンス

「IEEE 802.11r について フレームフォーマット - eggmanの日記」の続きです、fast BSS transitionのシーケンスを眺めていたら、高速化の理由が分かった。とりあえずWPA-PSKの場合のみを考えます。

高速化のポイント

  • Deauthしない
  • WPAの4 WAYをしない。
  • そのかわり、Auth,Auth,Reassoc Req, Reassoc Respで4WAYの情報をやり取りする。
  • 通常の場合よりもフレームが18個から6個に減るので、ローミングは高速になる。
    • Normal：18
      • Deauth,ack,Auth,ack,Auth,ack,Reassoc Req,ack,Reassoc Resp,ack,EAPOL,ack,EAPOL,ack,EAPOL,ack,EAPOL,ack
    • 802.11r fast BSS transition:8
      • Auth,ack,Auth,ack,Reassoc Req,ack,Reassoc Resp,ack

最初の接続

フレームのやりとりは既存のWPA-PSKと同じです。フレームに11rのIEが追加されています。

STA -Auth-> AP
STA <-Auth- AP
STA -Assoc Req(MDIE, RSNIE)-> AP
STA <-Assoc Resp(MDIE, FTIE[R1KH-ID, R0KH-ID])- AP
STA <-EAPOL-Key(0,0,1,0,P,0,ANonce,0)- AP
STA -EAPOL-Key(0,1,0,0,P,0,SNonce,MIC,RSNIE[PMKR1Name],MDIE,FTIE)-> AP
STA <-EAPOL-KEY(1,1,1,1,P,0,ANonce,MIC,RSNIE[PMKR1Name],MDIE,GTK[N],FTIE,TIE[ReassociationDeadline],TIE[KeyLifetime])- AP
STA -EAPOL-Key(1,1,0,0,P,0,0,MIC)-> AP

高速ローミングのシーケンス

Deauthなしで、Target APにAuthできる。

STA -Auth(FTAA,RSNIE,MDIE,FTIE[SNonce,R0KH-ID])-> -> Target AP
STA <-Auth(FTAA,RSNIE,MDIE,FTIE[ANonce,SNonce,R1KH-ID,R0KH-ID])- -- Taret AP
STA -Reassoc Req(RSNIE,MDIE,FTIE(MIC,ANonce,SNonce,R1KH-ID,R0KH-ID],RIC-Request -> TargeAP
STA <-Reassoc Resp(RSNIE,MDIE,FTIE[MIC,ANonce,SNonce,R1KH-ID,R0KH-ID],RIC-Response)- -- Target AP

参考：IEEE 802.11r chapter 11A

IEEE 802.11r について フレームフォーマット

http://standards.ieee.org/getieee802/にてIEEE 802.11rの仕様書がダウンロードできるようになってた。
802.11rとは、WiFiで高速ローミングするための規格になります。パラパラと眺めてみて、フレームフォーマットについて分まとめてみた。

  • fast BSS transition : 高速ローミングのこと
  • Current AP : 現在繋がっているAP
  • Target AP : ローミング先のAP
  • Managementフレームに追加されたIE
    • Beacon:MDIE
    • Association request : MDIE
    • Association response : MDIE, FTIE
    • Reassociation Request : MDIE, FTIE, RDIE
    • Reassociation Response : RSNIE, MDIE, RDIE
    • Probe Response : MDIE
    • Authentication : RSNIE, MDIE, FTIE, TIE, RDIE
  • IEの要素
    • MDIE : MDID, FT Capability and Policy
    • FTIE : MIC Control, MIC, ANonce, SNonce, Optional Parameters
    • TIE : Timeout Interval Type, Timeout Interval Value
    • RIE : RDIE Identifier, Resource Descriptor Count, Status Code
  • 追加されたフレーム(Action frame)
    • FT Request : STA -> AP
    • FT Response : AP -> STA
    • FT Confirm : STA -> AP
    • FT Ack : AP -> STA

どうして高速でローミングできるかはまだわからない。また後でしらべてみます。

micro SDサイズ WLANカードの内部写真

Speectecのmicro SDサイズの WLANカードがCES 2009にあわせてFCCに登録されてた。おそらくSDW-823だと思われます。製品ページによると、11bgのみで、11nには対応しなくなったっぽいです。
FCCIDはS2Y-MWLAN-11B-Gです。(FCC)
内部写真もあった。

ついに発売されるのかな。

IGDA SIG-GT12「ゲームにおけるスクリプト言語の現状」のレポート

http://www.igda.jp/modules/eguide/event.php?eid=58へ行ってきた。

CRI Scriptの実装の話が面白かったです。

メモをとりました。内容は保証しませんので…

CriScript @ errorの人

  • 趣味と実益をかねて開発
  • コンシューマーゲームのゲームエンジンの組み込みをやっている
  • 大規模ゲーム開発では、スクリプト言語はスタンダード　特にヨーロッパ、アメリカ
  • 予言 五年後、ゲームコードの殆どはスクリプト言語で記述される。
  • CriScript オープンソースのECMA262実装 Win32/Xbox360/OSX/iPhone
  • SPUにも移植したいが…
  • 標準仕様の採用
    • 利点 ある程度こなれた言語仕様 既存のテストコードが使える オープンである
    • 欠点 仕様規模が大きい(ゲームには不要そうな機能も) ヲレ拡張が難しい 組み込みに向いていない仕様もある
  • Webのアクセス数
    • 200-300/day アメリカ、日本、　意外とロシアが多い。
  • 実装編
  • flexは使わないで自前コード
  • バイトコードの選択がパフォーマンスに影響する。慎重に。
    • CIL, JAVA, ASのバイトコードを検討
    • CILの中身を知りたくて、CILを選択したが、CILはどちらかといえば失敗-
    • CILはスタックマシンなので効率が良くない
    • 中間フォーマットとは良いが、最終ターゲットのバイトコードとしては効率が良くない。
    • 独自命令を追加した。
    • 今だったらLLVMがオススメ
  • Q バイトコードの乗り換えはどれくらいかかるのか。
    • A やりたくない。 コードジェネレータとVMを書き換えないといけない。
  • スタックマシン
    • 実装が容易
  • ディスパッチループ
    • 単純なスイッチ文
    • ダイレクトスレッド、コンテクストスレッド やってみたがあまり効果が無かった。
  • Q スタックマシンが最適でない　どれくらい違うと考えているのか by 笹田先生
  • A スタックだと、4回かかるバイトだと1回でできる。3,40%早くなるのは
  • Q コードをみたけど、最適化の余地がるby 笹田先生
  • A ためしてみます。
  • BooSt::Regenを使ったらVMの30%のコード
  • 今後はいらないライブラリをリンクしないようにしたい。
  • オブジェクト管理
    • リファレンスカウンタ、GC
    • GC自動発動は無し。明示的にGCする。
  • ネイティブコード生成
    • ゲーム機としてチャレンジング
    • セキュリティモデル
    • 今後は非署名コードは実行できない。
      • C++ソースファイルを生成すれば可能ではあるが、スクリプトの意味が無い。
    • JITパフォーマンス
  • CriScriptでは
    • 静的なevalのみ許可
  • パフォーマンス
    • ネィティブコード比 1/7-1/20ぐらいのパフォーマンス
    • Luaのパフォーマンスをリファレンスにしている。
  • 最適化の軸
    • VM最適化
    • アーキテクチャ毎に最適化する。
      • IA32 命令数を減らす。正統的な最適化が有効 まずIA32で最適化する
      • PPC パイプラインをつまるところ
      • ARM バスが貧弱なことが多いので、バスのR/Wを減らす。
      • プロファイリング環境を整えれば、モチベーションが保てる
      • コード生成をアセンブリレベルでよく見る。
    • バイトコードのコード生成最適化
        • ピープホール最適化が一番効く。
    • 高速化に適した言語仕様の拡張
      • class定義、明示的な型指定:型毎の演算命令を用意する
      • ゲーム機にフィットする拡張
    • (スクリプト言語で最適化したコードを書く)


Luaの発表とパネルのメモもあるけど、中途半端すぐる。

MMC plus HS　と SDXCについての予想

MMC(wikipedia)には、MMC Specification 4.0から8bit modeが追加されている。
8bit Modeではピンが13ピンになってます。
http://data.tumblr.com/FJeRSVI5til6b6ykbKFvtBuGo1_250.jpg
beagle boardには8bit対応スロットが搭載されているので、対応カードを欲しいなぁと思っていたら、トランセンドが作っていた。4GBのMMCplus HSカードを注文しといた。


MMC 4.3では、8bit modeでHS対応の場合をバス上の最大データレートが52MBbytes/sec (8bit x 52MHz)となります。
ちなみに、MMC 4.3の規格書は、JEDECのページから、登録すれば無料ダウンロードできる。(Home | JEDEC)
MMC 4.4では最大104MBytes/secとなる(NE)ので、おそらくバスのクロックが104MHzとなるんじゃないかな。


SDXCも今年は、104Mbytes/secを達成するということ(techon)なので、、MMCと同じく8bit Modeを新たに作って、バスクロックを104MHzにすると予想してみる。(52MHzのDDRにして、両エッジを使うという可能性もあるが。）


でも300MBytes/secを目指すためには、この方向では厳しいです。変調が必要でしょ。