2019年5月5日日曜日

そろそろ転職します(前編)

4月10日に今の所属会社に退職の意思表示をして、5月一杯で退職して、6月から新しい会社で働き始めることになりました。5月は有給消化期間のため丸々お休み(1日だけ出勤)です。世間では「今年のGWは10連休」と騒がれてますが私は36連休。とはいえ、GW中でも普通に仕事があり、GW後も引っ越し関連の対応で実質14日ほどしか休めませんが。
退職というと、リストラされたとか今の会社が嫌になったとか、何かしらネガティブな事由が付き纏いがちかと思います。しかし、今回の退職(転職)は至ってポジティブなものです。リストラされた訳でもないし、今の会社が嫌になった訳でもありません。むしろ、今の会社には愛着があります。なんやかんや丸5年も勤めてきたので。ただし、詳細を書くと色々な人に迷惑が掛かる可能性があるので、それについて今回は触れません。

就職氷河期と言われていた2002年、私は大手と呼べるほどには大きくもなく、ベンチャーと呼べるほど小さくもない一部上場企業(※就職当時はJASDAQ)へ新卒入社して、2014年に現所属会社に転職しました。
最初の会社は独立系SIerと呼ばれる類の会社で、顧客先に常駐して仕事をする(※派遣ではない)という、よくある下請(?)業務主体のIT企業です。世間で「IT企業」と呼ばれる企業の大半がこの業態です。
下請業務というと、某拝承や某電電子会社といった顧客に言われるがまま仕事をしているイメージかもしれません。大筋ではその通りですが、大筋さえ合わせれば手法は幾らでもあるので、ヒラの頃はそれなりに楽しめてました。しかし、中間管理職になったあたりで「このままじゃアカン」と思い辞めることにしました。
マネジメントに興味が無い訳ではありません。中間管理職としてキャリアを積むことで、汎用的なマネジメントの技術も身につくとは思いますが、汎用的なマネジメント技術であればPMPなどの資格や非マネジメントの仕事の中でも身につきます。ドラッガーや貞観政要やロビンソン・クルーソーといったマネジメント教本を読むのでも良いと思います。
ロビンソン・クルーソーをマネジメント教本と呼ぶのはあまり一般的ではないかもしれませんが、事業とマネジメントの本質が下手なマネジメント教本よりも分かりやすく書かれています。
組織の理の中で実現できる範囲のものが自分のやりたい事と一致するのであれば、そのまま中間管理職としてキャリアを積むのがベストですが、私は自分で事業を企画してプロジェクトを起ち上げたいと思っていました。しかし、下請業務を生業とする独立系SIerでは、それは限りなく不可能に近いです。そこで、2014年の転職時は、下請業務を行わず自社サービス or 自社製品の開発販売を生業とし、且つやりたい事の方向性が近い企業に絞って転職活動を行い、縁あって現所属会社に転職しました。

現所属会社でどのような形で暗躍したのか細かく書きたいところですが、前述の通りそれについては省略します。結果的に当初の目論見通り、新規サービス開発プロジェクトの起ち上げに成功し、サービスイン直前という状態まで駒を進めることができました。ただし、やんごとなき事情によりそれはまだ世に出せてません。通常ならここで計画頓挫となるところですが、やや厳しい条件付きであるものの計画頓挫を回避できる道筋が開けました。その条件のひとつが転職です。何かしらネガティブな理由が付き纏いがちの退職原因がポジティブだと言い切れるのはその為です。
転職により、お賃金は若干(年収ベースで250万円ぐらい)ダウンすることになりますが。私の場合、年収ダウンについては問題ありません。2014年の転職前の時点から年収ベースでだいたいそれぐらいアップしているので、元サヤに戻ったと考えることができます。私はそもそも殆どお金を使わないので、増えた年収分の資金は老後の蓄えとして全額投資に回していた(※FXやパチンコではなく仕組債や国債などのミドルリスク〜ローリスクの投資、あとまだ資金作りの途中で手を出していないけど不動産投資にも手を出そうとしていた)ので、追加投資しなければ余裕で生活できます。

ただし、転職することに伴い都心(銀座)に住むメリットが無くなったので、足立区に引っ越し(都落ち?)をすることにしました。現所属会社には、会社からの一定距離内に住めば手当が付き、その中から各自定期代などを支払う「近距離手当」と呼ばれる素晴らしい制度があります。独身貴族なら会社の徒歩圏に住むのがベストです。一人住まいのワンルームであれば、会社の徒歩圏(銀座)に住んでも横浜や千葉といった郊外に住むのと実質変わらない家賃で生活できます。しかし、今度の転職先にはそういう制度が無いので、多少の通勤時間を要してでも家賃が安いところに住むことにしました。
都心にオフィスを構える従業員が一定数(10人以上ぐらい?)以上の会社は、例外なくこの制度を採用することを都条例で義務化すべきかも。例えば、ワンルームの家賃相場14万円の渋谷にオフィスを構える場合、郊外水準(7万円前後)にするために7万円の近距離手当を支給必須みたいな形。これが実現できれば、朝の通勤ラッシュがかなり解消され、子育て環境等の都合で郊外に住まざるを得ない所帯持ちは快適に通勤できるようになり、都心住まいでも問題ない独身貴族は優雅に徒歩通勤でき、会社は終電に縛られないソルジャーを抱えることで労働力upでき、これらにより大幅な生産性向上を期待できます。更に、会社のコストとしては微々たるものなので、それすら払えない企業は稀(そもそもそんな弱小企業なら都心にオフィスを構えるべきではない)かもしれませんが、そういった分不相応な企業を都心から排除できることで、オフィスの都心一極集中問題も緩和できるかもしれません。(派遣や偽装請負で取引先常駐の社員はどうなる?みたいな問題があるかもしれませんが、その場合、常勤地の家賃相場で雇用元が支給する想定。そうすれば、労働力受け入れ側の企業が実質その負担をすることになる(近距離手当込みの価格を上乗せすることになる)ので何ら問題ないはず)
引越し先の候補は当初、足立区ではなく故郷の静岡(実家)でした。郷愁とかではなく、シンプルにそれが一番コスパが良いので。IT系技術職の業務であればSlack、AWS、GitHub、Skype、VPNなどを駆使すれば、オフィスに行かなくても普通に仕事ができます。逆に、オフィスに通わないと仕事が出来ないような昔ながらのIT企業は、現代の技術についていけていないので、IT企業として失格だと思います。
だからといって、技術職であれば全員リモート勤務にするのが良いとは思っていません。リモート勤務は、人によってかなり向き不向きがあるので。
例えば、「家だと全然仕事ができない」とか「休日に仕事をしない」という人はリモート勤務には向きません。このタイプの人は、オフィスに行くことでスイッチを切り替えるタイプなので、自宅よりもオフィスで仕事をした方が生産性が上がります。
そして、大半の人がこのタイプに属します。
何故なら、大半の人は幼少期から幼稚園や保育園、小学校、中学校、高校といった集団行動の場と自宅でPublicモードとPrivateモードを切り替える生活に慣れており、Publicモードの時にプロとして働くスキルを身に付けているので。
逆に、プロとしての能力をPrivateモード中心で習得した人は、オフィス勤務よりリモート勤務の方が生産性が高くなります。例えば、漫画家とかは根っからのPrivateモード特化型です。漫画家に限らず、クリエイターの大半はPrivateモード(趣味の延長)でプロとしての技術を習得するので、オフィスよりも自宅等(※自宅とは限らない)ステートレスなスタイルで仕事した方が生産性が上がる人が多いです。
業種にもよってもマチマチですが、私の経験上プログラマの場合、リモート勤務向きの人は圧倒的に少数派ですがゼロではありません。恐らく、10人居れば1〜2人程度がリモート勤務向きという感触です。なので、「プログラマは全員一律でリモート勤務」としてしまうと、トータルの生産性が落ちる筈です。ただし、一定数(1〜2割程度)リモート向きの人が居ることを考慮すると、一律全員リモート勤務禁止とするのは合理的ではありません。ついでに、プログラマの場合、社会人として本来あるべき姿のリモート勤務に不向きな人材よりも、社会不適合者に近いリモート勤務向きの人材の中にスーパーマン(生産性が通常の人材よりもズバ抜けて高い人材)が居るケースが多いので。(だからこそ、リモート勤務ができるインフラが他業種と比べて整備されているのだと考えることができます)
しかしながら、大きな会社だと、その1〜2割の選定で絶対にもめる(明らかにリモート勤務に向かないタイプの人が志願したり、リモート勤務に選別された人に対して不平等だと感じて拗ねたりする)ので、リモート勤務を制度として導入するのは恐らく不可能です。私の現所属会社は結構大きな会社で、一応仕組みとしてリモート勤務は存在しますが希望しませんでした。そもそも「その方が生産性が上がるから」という理屈では通らないだろうし、通すべきではないと思います。マネジメント職(※私のいうマネジメント職というのは取締役以上)の社員から「この従業員ならリモートでも良い」と認められるだけの実績がある人限定で認めるのなら良いと思いますが。
私はPrivateモード中心でプログラミング技術を習得して、それが現在の食い扶持になっているので、リモート勤務の方が生産性が上がるタイプです。なので、仮にリモート勤務で働くとして、出社頻度が月平均4回程度(週1回程度)であれば、静岡から東京までの新幹線の交通費が月間5万円ぐらい(高速バスを使えば半額)で収まり、都内やその近郊だと家賃だけで6〜10万円程度するので、家賃がゼロで済む実家から新幹線通勤した方がお得だと言えます。
とはいえ、最初からリモート勤務ではなく「まずは常勤で」という条件をのんで採用されましたが。実際の業務状況を見て、問題無さそうなら将来的にリモート勤務に切り替える想定です。(※当然ですが、これは独断ではなく転職先の社長から了承を頂いています)
常勤の期間中は東京に居る必要があるし、リモート勤務切り替え後も暫く(1年ぐらい?)は都内の自宅で対応して、それで特に問題無さそうだったら静岡に移る作戦です。そこで、ひとまず普通に都内で引越し先を探し、家賃相場が安いという理由で足立区をチョイスしました。

足立区は、どういう訳か23区内の中で都心へのアクセスが良い割に家賃相場が安いです。最初家賃相場を見た時「スラム街かな?」と思い、治安面などが若干気になって数回視察してみたのですが、ヨーロッパとかよりはずっと安全でした。
最近のヨーロッパは、(経済的に不安定なこともあってか)かなり治安が悪く、ベネルクス三国(特にベルギー)やイタリア北部といった昔はそこそこ安全だった所ですらスリが沢山います。
私も1回ベルギーでスリに遭い、ポケットに入れていたスリ用の小銭入れ(※正確にはスリ用ではなくチップ用の小銭入れ)がスられてしまい、5€損しました。本命の財布は首からぶら下げて服の下に入れるなどの対策をしないと、安心して街歩きができません(経験上、黒人の若者が近づいてきたり話しかけてきたら、ほぼ100%スリなので警戒する必要があります)。しかし、足立区はそういうレベルではなく、せいぜい自転車泥棒が多かったりとかその程度で、警察のパトカーが頻繁に巡回しているので安心できます。巡回しているのが警察ではなく軍だったら少し怖い(ヨーロッパでは最近テロが多い関係で軍が巡回していることが多い)ですが、今のところ足立区で軍による巡回は無かったので、テロ等の心配も無いかもしれません。

引越し先を選定しようとした時、レオパレス問題の影響で引越者が続出しているとかで、物件の回転速度が異常に早く少し大変でした。ネットでの内覧予約は概してアテになりません。条件が良い所はすぐ埋まってしまいます。ネットで内覧予約をして2〜3日程度(通常であれば1週間程度)残っている物件があったら、条件面を疑ってかかった方が良いというレベルでした。こういう状況下では、ネットには頼らず住みたい地域の不動産屋を訪問して管理物件の内覧をし、良ければ即断即決という形がベストです。

引越し先が決まったのは良いですが、現住居(銀座)は家具・家電付きの物件なので、引っ越しに際して家具・家電を買い揃えるのも中々面倒でした。
Amazonとかのネット通販だと配達日がバラけてしまうので、まとめ買い用途には向きません。こういう場合、家具はニトリなど、家電はビックカメラなどの全国に店舗を持つ大型店を使うと便利です。こういった店舗なら独自の配送系統を持っていたりする(特にニトリの家具部門の独自配送系統は安くて良い)ので、指定日付にまとめて発送といったコントロールがしやすいし、設置も手伝ってくれます。(ちなみに、Amazonはリスト機能が便利なので、必要な家具・家電の買い物リスト作成用途でのみ利用しました)

あとは、インターネットをどうするかが悩ましい。
引っ越し業者に設置サービスを依頼するとキャッシュバックみたいなヤツがあってお得そうだったのですが、固定回線ではない方が都合が良いので全部お断りしました。
現住居(銀座)ではマンション内共有の無料インターネットがありますが、新住居にはそういったものが有りません。そのため、ネットはしばらくの間、スマホのテザリングだけで済ませることにしました。

そのため、YouTubeやニコニコ動画などはほぼ見れなくなります。
固定費削減も兼ねてdアニメチャンネルを解約することにしました。元々ニコニコプレミアムに入っていたのですが、ユーザ投稿の動画を殆ど見ず公式のアニメぐらいしか見ていなかったので、ニコニコプレミアムを解約して代わりにdアニメに入会したのですが、暇つぶし用途としては中々コスパが良いのでオススメです。反面、観はじめると止まらず、生活のリズムが狂ってしまうのが微妙です。現所属会社は裁量労働制なので何時に出社しても大丈夫ですが、転職先は就業時間がカッチリ決まっているので不規則な生活ができなくなってしまいます。なので、良い機会だから解約しようかなと。

同じような理由でソシャゲも全部引退済みです。
ソシャゲは平常時それほど通信しませんが、アプデやイベントの都度数百MBオーバーのデータ通信が高頻度で発生するので、スマホテザリングだとキツイ。実のところ最近はソシャゲは全くやっていなくて、代わりにFXをやっている(※先述の投資とは別腹で、FXは完全に遊びでやっている)のですが、そちらはアプデはめったになく(そもそもアプリサイズも小さく)、ゲーム内イベントは無い(イベントは常にリアルでのみ発生する)から128Kbpsで問題なく遊べます。(FXは引退せずに継続予定)

私のスマホはOCNの1日100MBしか高速通信できないプラン(音声通話付き格安SIMで月1500円ぐらいで使えるやつ)で、高速通信を使い切っても128Kbpsで通信できるから、恐らくテザリングのみで何とかなるはず。OSやXCODEのアップデートがかなりしんどいですが、それらはそんなに高頻度に発生しないので、都度ネカフェや職場で済ませば大丈夫だろうと高をくくってみることにしました。

ですが、恐らくそれでは色々とキツイことが想定されるので、スマホプランの変更 or WiMaxでも導入してみようかと考え、WiMaxのプランを少し調べてみたのですが、月額1,000円台で「業界最安値!」などと謳っているヤツは軒並みクソですね。
安いのは初月だけで、2ヶ月目〜24ヶ月目は結構高くなり、25ヶ月目以降は安くても4000円/月前後が相場のようです。(初代WiMaxの頃と比べれば25ヶ月目以降の価格でも十分安いのですが)
しかも、2 or 3年縛り契約で、尚且契約月でなければ解約するのに違約金が掛かるものが多いので、キッチリ36ヶ月使い切ったタイミングで忘れずに解約必須(36ヶ月で解約しないと損をする)というのがかなり面倒くさい。
契約更新後(37ヶ月目)に再び1ヶ月目の料金に一旦リセットされるのであればまだ良いのですが、そうではなく37ヶ月目以降も25ヶ月目以降と同一料金だから、37ヶ月以上使うのは完全に損です。(かといって36ヶ月未満で解約するのも損)
何故そのようなゴミ仕様にしたのか...
スマホのプランでも似たような「なんちゃって格安プラン」が多いのですが、WiMaxも中々酷い。モバイル業者って、どうしてこんなにクズばかりなのか。初月の固定費を落としまくって「たったxxx〜円で使えます!」というキャッチーな謳い文句にしたかったとか、そんな感じの頭が悪そうな発想でそういうゴミ仕様を考えたのだろうと想像できますが、固定費を気にするユーザーなら普通に「永続的にその値段じゃなければNG」と考えます。初月の安さだけで釣り、あとは契約月という仕組みにより解約難度を上げるという、「騙せれば儲けもん」という商売スタイルは詐欺の手口に近い。(※なお、これは契約者責任なので詐欺ではなく「契約書を読まない方が悪い」という理屈が通るので詐欺にはなりません)
そこら辺を加味すると、縛りなしWiFiというのが良さげかも。
月額3200円 & 13ヶ月目以降は2800円 + 転送容量制限なし※ + 期間縛りなしとのこと。
※一時制限はある(WiMax回線: 10GB/3day, SoftBank回線: 3GB/day)
・月間平均コストが良い感じ
・契約を継続し続ければ安くなる
・「契約月」とかいう客に不便だけを強いさせるゴミ仕様が無い
軒並みクズ揃いのWiMax業者の中で唯一真っ当に見えるプランがコレでした。

これで一通りの準備が整ったかな。
やっぱり引っ越しは大変です。
転職ネタをメインに書こうと思ったら、いつの間にか引っ越しネタがメインになってしまったかもしれない。

2019年4月1日月曜日

自機狙いのハードウェア化

VGS8(6502)でゲームを作っていて、自機狙いにATAN2が使えないのが中々辛い。
ATAN2が使えないならDDTとかの手法もありますが、DDTをやるにも除算が重いのでこれもまたキツイ。
という訳で2点間の角度を求める機能をハードウェアで作ってしまいました。
概ね下記のような形。
https://github.com/suzukiplan/vgs8/commit/c0437fa5c453a1df0b62072bff0da9680b0ab302
※上記commit時点では若干バグがあります(最新版では治っていますが)

要約すると、MANUAL.mdに書いてある通りですが

- $5A10 x1 の座標をstore
- $5A11 y1 の座標をstore
- $5A12 x2 の座標をstore
- $5A13 y2 の座標をstore
- $5A14 load することで (x1, y1) (x2, y2) の角度を求める
というもの。

角度は360度だと8bitに収まらないので、0〜255の特殊なラジアンです。
赤丸が (x1,y1) で 青バツが (x2, y2) とした時の求まるラジアン値は下図のようになります。
(x2, y2) が真上の時が 0 で、時計回りで最大255まで増えます(256 = 0で一周)。

これにより、6502でも無事自機狙いの弾を作ることができました。
だいたい自機を狙えています。
256方向弾ではなくメモリ節約のため32方向弾だから若干ズレますが ^^;

少し大変ですが、やっぱり実際にゲームを作りながら検証しないと必要な機能が漏れてしまったり、不必要なハードウェア機能を実装してゲーム機としてのシンプルさを欠くことになってしまうので、実際にゲームを作りながらゲーム機をつくることは重要。ゲームエンジンにしても然りですが、昨今のゲームエンジンは無駄に高機能なものが多くてあまり美しくないと思っていたりする。

2019年3月25日月曜日

VGS8のデバッガ

VGS8でHello, World!を作ってみて、CPUをデバッグするツールめいたものの必要性が高まったからデバッガを作り始めました。ただ、単にCPUデバッグだけを目的としたツールではなく、ゲーム開発時にも使い物になるレベルのものが欲しいところ。

以前、ファミコンのゲームを開発した際、コマンドライン上でレジスタ値やメモリダンプの簡易チェックができるCLIが欲しかったのですが、そもそも「コマンドラインでゲームをステップ実行できるNESエミュレータ」というものが(軽く探してみた限りですが)見つかりませんでした。GUIでメモリダンプやステップ実行できるものなら幾らかありましたが。

という訳でコマンドライン上で実行できるVGS8のデバッガ(vgsrun)を作成。
実行すると上図のように現在のプログラムカウンタ上の命令を逆アセンブルしながら、レジスタダンプ(a, x, y, s, p)を右側に出力します。(赤くなっている部分は前ステップからレジスタ値が変化したもの)

そのまま実行すると、1フレーム分の命令実行終了で自動的に終了します。
※コマンド引数で実行するフレーム数を任意に指定可能

先日作ったVGS8版Hello, Worldを1フレーム実行した結果


これで、ゲーム開発もVGS8本体開発も大分捗りそうです。
将来的にはもっと拡張して、
・ブレイクポイントの途中書き換え
・ステップ実行
あたりも欲しいかも。

2019年3月24日日曜日

VGS8でHello, World!

VGS8の基本的な実装がだいたいできたので、お馴染みの「Hello, World!」を作ってみました。

まず、vgs8リポジトリでは当初、VGS8エミュレータのコアプログラムしか無い状態だったので、テストするにはHALを作成する必要があります。そこで、リポジトリ内にmacOS用アプリ(CocoaApp)としてHALを実装。
https://github.com/suzukiplan/vgs8/tree/master/hal/mac

そして、6502でHello, World!を出力するプログラムを作成。
https://github.com/suzukiplan/vgs8/tree/master/examples/hello

ソースコード本体は20行ちょっと(こんな感じです)

すごくシンプルですね。
ファミコンでHello, World!を作る場合との違いとしては、
・iNESヘッダーとか要らない
・RESET割り込み不要(VGS8の場合、RESET割り込みはプログラム側で検知できない仕様)
・必要な初期化処理はCMAPレジスタの設定ぐらいなので楽(実のところ、このコードであればCMAPレジスタの設定自体が不要だったりする)
・nametableのアドレス計算が異なる
ぐらいなので、ファミコンのプログラムが書ける人なら、「あぁ、なるほど」と簡単に理解できるかと思います。

上記を作成したCocoaAppで動かしてみた結果が下図です。
VGS8でHello, World!が動きました。
良かった良かった。

こうやって書いてみると非常にアッサリと動いたように勘違いされてしまうとアレなので、念の為補足するとかなり大変でした。
absoluteのエンディアンを間違えていたり、branchの加算時の起点を間違えたり、Windows Bitmapのパレットの仕様を間違えていたり、あとはプログラムを作ればほぼ必然的に発生するケアレスミス群。

一番キツかったのが、自作MOS6502エミュレータのバグ取りですね。
最終的にXCODEのデバッガでexecuteにbreak pointを仕掛けて、1ステップづつ6502コードを実行してレジスタやRAMが想定通りに更新されるかチェックする形でデバッグしました。
コマンドラインで動くデバッガ作らないとなぁ...

2019年3月23日土曜日

MOS6502エミュレータ作成

VGS8に搭載するCPU(6502)の実装をgithub他で探してみたのですが、流石有名CPUだけあって色々とありました。ただ、6502ぐらいシンプルなCPUなら折角だから自前で作ってしまおうということで、自作しました。(自前で実装した方が色々とカスタマイズもしやすいですし)
https://github.com/suzukiplan/vgs8/blob/master/src/cpu.hpp

1ソースならぬ1ヘッダで実装。
1ヘッダで作れてしまうシンプルさは流石6502。
LLVMとは次元が違います。

現時点ではまだ動かしてテストしていないので、バグだらけかもしれません。
(特にindirectは資料すら読まずカンで作ったのでヤバイかも)

ややVGS独自の拡張が入った状態ですが、ファミコンのエミュレータにも応用できるかもしれないので、コレでファミコンのエミュレータを作り、test romsでテストするという手もあります。(それは流石にやりませんが)

2019年3月22日金曜日

VGS8のメモリマップを考える

ファミコンのプログラミングができる人じゃないと理解できない(ので、ブログで書いても大抵の人が理解できない)内容ですが、VGS8のメモリマップを考えました。
下表のような形です。
AddressUsage
$0000〜$00FFZero page
$0100〜$01FFStack
$0200〜$4FFFRAM
$5000〜$53FFSprite OAM (4x256)
$5400I/O port (RW): PRG Bank of $8000〜$BFFF
$5401I/O port (RW): PRG Bank of $C000〜$FFFF
$5402〜$5BFFother I/O ports (WIP)
$5C00〜$5FFFPalette
$6000〜$63FFBG nametable 0 (LT; 左上)
$6400〜$67FFBG nametable 1 (RT; 右上)
$6800〜$6BFFBG nametable 2 (LB; 左下)
$6C00〜$6FFFBG nametable 3 (RB; 右下)
$7000〜$73FFFG nametable 0 (LT; 左上)
$7400〜$77FFFG nametable 1 (RT; 右上)
$7800〜$7BFFFG nametable 2 (LB; 左下)
$7C00〜$7FFFFG nametable 3 (RB; 右下)
$8000〜$BFFFProgram 0
$C000〜$FFFFProgram 1
ゼロページとスタックはファミコンと全く同じですね。
あと、$8000以降に16KB区切りで2つのプログラムデータを置ける点もファミコンと同じです。
それ以外はかなり弄りました。

まず、最大の違いはRAMです。
ファミコンの場合、基本マッパー(mapper0)のRAM(WRAM)は$0200〜$1FFFで、$2000〜$3FFFがI/Oやミラーですが、VGS8では$0200〜$4FFFまでの19KBを丸々RAMとして使うことができます。

そして、ファミコンの場合、OAM(スプライトのメモリ)をPPU側に持っていて、RAMの任意1ページ(256バイト)をDMA転送して使うのですが、VGS8の場合、$5000〜$53FFまでの1KBがPPUのOAMにダイレクトマップされています。つまり、スプライト描画にDMA転送しなくても良いのです。スゴイ!(なお、スプライト表示数の上限はファミコンは64個 & 水平最大8個ですが、VGS8は256個 & 水平上限が無制限です)

$5400〜$5BFFはI/Oポートとしてリザーブしました。
用途はまだ考えていません。
シンプルなPPU/APUアクセスに加えて、C言語のmemmove関数相当のメモリブロック転送機能を実装する予定です。

$5C00〜$5FFFの1KBはパレットデータです。
ファミコンの場合、スプライトとBGそれぞれに2bitカラーのパレットを4個割り当てることができますが、VGS8は旧VGSの仕様を引き継いで、256色パレット1つをBG/FG/スプライトのそれぞれで共有します。つまり、VGS8の最大同時発色数はシンプルに256色となります。

$6000〜$7FFFの8KBはドカンと全部nametableです。
ファミコンはBG4スクリーン分のnametableがあって内2スクリーンは必ずミラーですが、VGS8はBG/FGそれぞれ4スクリーンフルに利用することができます。
また、FGというファミコンには無いグラフィック機能があります。
ファミコンのBGは、「すべてをスプライトの背面」or「すべてをスプライトの前面」の何れかしか表示することができませんが、VGS8では「BGは必ずスプライト背面」「FGは必ずスプライト前面」に表示する仕様です。
しかも、I/OポートでPPUへアクセスする必要が無く、OAMと同様PPUのnametableにダイレクトマップされる仕様です。

また、ファミコンの場合、バンク切り替えをするにはMMC3やMMC5といった特殊mapperを用いる必要がありますが、VGS8は標準機能としてプログラムとCHR両方のバンク切り替えをサポートしています。
ただし、コナミのグラディウス2等で使われているCHRの部分領域単位でのバンク切り替えには対応しません。この点についてはCPUの速度がファミコン比で4倍以上ある(ファミコンは1.79MHzですがVGS8は今の所8MHzにする予定です)ので、パワーでゴリ押せば大丈夫だろうと思います。

楽しくなってきた。

VGS8 - 現代のテクノロジーで新しい8bitゲーム機を作る

VGS3の開発が完全に滞っています。

VGS3は完全にオリジナルのCPUを用いた仮想ゲーム機ですが、CPUを概ね設計しきった辺りで飽きてしまいました。アセンブラやデバッガ等を諸々作っていくのがあまりにも面倒くさくて...

アセンブラやデバッガを作るのが面倒なら既存のCPUを使ってしまえば良いじゃない

という風に思ったのですが、それって著作権的に大丈夫なのだろうか?

ということで、著作権法を読んでみたところ、どうもそれならシロらしい。
以下その根拠となる法律(著作権法第10条)です。
(著作物の例示)
第十条 この法律にいう著作物を例示すると、おおむね次のとおりである。
  1. 一 小説、脚本、論文、講演その他の言語の著作物
  2. 二 音楽の著作物
  3. 三 舞踊又は無言劇の著作物
  4. 四 絵画、版画、彫刻その他の美術の著作物
  5. 五 建築の著作物
  6. 六 地図又は学術的な性質を有する図面、図表、模型その他の図形の著作物
  7. 七 映画の著作物
  8. 八 写真の著作物
  9. 九 プログラムの著作物
2 事実の伝達にすぎない雑報及び時事の報道は、前項第一号に掲げる著作物に該当しない。
3 第一項第九号に掲げる著作物に対するこの法律による保護は、その著作物を作成するために用いるプログラム言語、規約及び解法に及ばない。この場合において、これらの用語の意義は、次の各号に定めるところによる。
  1. 一 プログラム言語 プログラムを表現する手段としての文字その他の記号及びその体系をいう。
  2. 二 規約 特定のプログラムにおける前号のプログラム言語の用法についての特別の約束をいう。
  3. 三 解法 プログラムにおける電子計算機に対する指令の組合せの方法をいう。
上記は、飽くまでも「著作物の例示」なので、ここに含まれていないからといって著作物ではないと判断することはできませんが、第3項で「プログラムの著作物を作成するために用いるプログラム言語、規約及び解放は著作権法では保護しない」と明示的に著作物であることが否定されているので、それ(プログラム言語、規約及び解放)に関しては著作物ではないと判断できます。つまり、C言語やJava言語といったプログラム言語には著作権が無いことになります。そして当然ながら機械語(アセンブリ言語)もこの法律でいうプログラム言語に該当するので著作権法での保護は無い(そもそも出来ない)と判断できます。

法律的にも問題無さそうだということが分かったので、ファミコンのCPU(RP2A03)をベースにして新しい仮想ゲーム機を作ってみることにしました。

その名もVGS8
https://github.com/suzukiplan/vgs8

昨年末あたり、ファミコンのプログラミング方法を解説したマニュアルを書いたのですが、実はその目的がコレを作るためです。ファミコンのハードウェア仕様を把握して実際にゲームプログラムを作ってみることで、ファミコンの仕様を受け継いだ新たな8bitゲーム機を作れるのではないかと。

この路線なら既存の素晴らしいツール(cc65)がそのまま使えるので、面倒なアセンブラ開発に悩まされる必要がなくなります。
今度こそはちゃんと完成させたいですが、完成できるかな?

合理的ではないものを作りたい

ここ最近、実機版の東方VGSの開発が忙しくて、東方VGSの曲追加が滞っています。 東方VGS(実機版)のデザインを作りながら検討中。基本レトロUIベースですがシークバーはモダンに倣おうかな…とか pic.twitter.com/YOYprlDsYD — SUZUKI PLAN (...