2021年6月6日日曜日

覇邪の封印(MSX版)の攻略手順

MSX版「覇邪の封印」の攻略情報を書きます。

MSX版には、パッケージに布製の地図とフィギュアが同梱されていますが、これらは単なるオマケではなく、ゲームをプレイするために必要なツールでして、説明書でもフィギュアの左足部分を現在位置に置いてプレイする旨が指示されています。実際に地図の上にフィギュアを置いてプレイしなければ開始直後(トウメガネやセンリノタマ入手まで)で詰みます。

という訳でマップ情報を掲載
スタート地点は左下の「アルカス城」です。

以下、チャートを記しますが、初見プレイなら見ないことを推奨。
(1) 初期地点の城(アルカス城)へ行く
→ コサーマへ会えと言われる
(2) 東2→北7→東1 で「ガリアの街」へ(入らなくてOK)
(3) 東3→北3→東2→北1→東5→北4→東3→北3 で「オルコの街」へ
※この間に「悪の商人」(ハゲてる方の商人)を1体以上狩れることを祈る
※「悪の商人」は1体につき2,000G & 知名度up
(4) オルコの街で「トウメガネ」購入(10,000G)
※以下、地図を見ながら移動
(5) 知名度+150以上になったら「エラトス城」へ行きライセンスをもらう
→ 魔獣を倒した時にキバ(換金アイテム)を獲得できるようになる
(6) エラトス城の東の島に居るコサーマに合う
→ フルキカブトを入手
→ 長老に500G払って使い方を確認
※魔具は基本的に長老に聞いて初めて使えるようになる
(7) 50,000G 溜めて鍛冶屋を雇う
※ここまでで恐らく初期装備は壊れているハズ
※全裸&素手で殴れば大丈夫なので初期装備は修理不要
→ 鍛冶屋を雇ったら タテ と ヨロイ を買う
※雀の涙程度だが防御力が上がり狩り効率がよくなる
(8) キバ300本貯まったらアレオイア城へ城へ行って武器を入手
→ イリスノセンプ(主人公用)を入手
→ 他の仲間の武器は今貰っても捨てるしかないのでもらわない
※主な狩場 = エラテアから一歩西に出たところのローバル(1体キバ4本)
※固定エンカなので効率よく稼げる
(9) 50,000G 溜まったらアルゴノフネを買う
※メノス or エラテアの市場で売っている
(10) 30,000G 溜まったらレッチノツエを買う
※まれにランダムエンカウントの魔道士からタダで貰える
(11) 30,000G 溜まったらセンリノタマを買う
※メノス or エラテアの市場で売っている
※マップの見える範囲が広くなる(無くても問題無い)
(12) 知名度が+6000を超えたら「シロノマキュウ」を入手
※500G払って使い方も聞いておくこと
(13) ウンムタクを狩って「イカリノカガミ」を入手
※500G払って使い方も聞いておくこと
※倒すと知名度が-1,000なので注意
※オルコの街の北(北東)側の平原でエンカウント
(14) 96,000G 貯まったら鍛冶屋の村でイリスノセンプを強化
(15) ローバル狩りである程度レベルを上げる
※この時点ではレベルMAXまで上げなくても良い
※魔獣の洞くつで防具を入手した後の知名度回復作業(24)でレベルMAXにする
※普通にプレイしても、この段階でまだ全然レベルMAXになっていない筈
※攻撃力のバーの上の青いバーが動かなくなればレベルMAX
(16) ブローニュの石碑へ行き呪文(ガリョウイザタタン)を覚える
(17) ガディアの街の市場で仲間(ガイ)を加入
(18) エラトス城へキバ300本を持っていきガイの武器入手
(19) アベイデア城付近の魔獣の洞くつ攻略して(クロノスノヨロイ→主人公)
(20) ドーリスの街の酒場で仲間(メディア)を加入
(21) アベイデア城へキバ300本を持っていきメディアの武器入手 
(22) 残りの魔獣の洞くつをすべて攻略(全員のヨロイとタテが揃う)
※盾の装備順を間違えるとトレモスが仲間に加わわらないので注意
※間違った盾を装備してしまった場合は持ち替えればOK
・オデッセ → 主人公
・ヘクトール → ガイ
・セイレーン → メディア
(23) 聖騎士狩りをして「コウモリノカメン」を入手しておく
※魔獣の洞くつ攻略で知名度が大幅にダウンして-10,000でカンストしている
※聖騎士は1体倒すと-9,999知名度が下がるがカンストしていれば問題無い
(24) 知名度回復作業
※ローバルを400体狩って知名度を+1以上にしておく
※この時点でレベルMAXになるのが理想
(25) ケーペウス神殿で仲間(トレモス)を加入
(26) 石碑で「トレモスキタレリ」を唱えてトレモスの武器と防具を揃える
(27) 鍛冶屋でトレモスの武器を強化
※資金に余裕があればガイ(更に余裕があればメディア)の武器も強化
(28) コサーマに再開
→ 呪文「キタレイアソン」を覚える
(29) イアソンの記念碑で呪文を唱えて3つの鍵を入手
(30) 地下神殿へ行きテラリン撃破
※地下神殿の鍵を挿す順序:
・天の鍵 = ウエ
・地の鍵 = ミギ
・冥の鍵 = ヒダリ
→ テラリン以外のエンカウントはすべて「逃げる」こと
※鍛冶屋無効(武器の耐久度が下がったら回復できない)
※呪い師無効(ココで使えないとなると加える意味がほぼ無い)
呪い師を雇う最適なタイミングは (28) の後
→ 最初にアイテム(イカリノカガミ、シロノマキュウ、レッチノツエ)を使う
→ 次に肉壁たち(トレモス、メディア、ガイ)に死ぬまで殴らせる
→ 最後に主人公が殴ればギリギリ倒せる
※復活の玉があれば余裕をもって倒せる(復活の玉込みならレベリング作業時間をかなり短縮可能な見込みだが、どの程度短縮するかは要調査)

2021年5月25日火曜日

S3+CloudFrontで配信している静的ページをFTPで更新できるようにした時のメモ

AWSのS3+CloudFrontで配信している静的Webサイトの更新をFTP(SFTP)でできるようにした時のメモです。

(手順)
  1. サーバ(EC2)にサイト更新用のアカウント(ex: webadmin)を作成してSFTPで繋がるようにする
  2. S3の内容をサーバのローカル(ex: /home/webadmin/web-root)にコピー
  3. lsyncdで/home/webadmin/web-root以下を監視(設定内容を後述)
    1. ファイル追加時:
      1. aws s3 cp でローカル→S3へ転送
    2. ファイル変更時:
      1. aws s3 cp でローカル→S3へ転送
      2. aws cloudfront create-invalidation で invalidation を実行
    3. ファイル削除時:
      1. aws s3 rm で S3からファイルを削除
      2. aws cloudfront create-invalidation で invalidation を実行

(/etc/lsyncd.conf)

settings {

    logfile = "/var/log/lsyncd.log",

    statusFile = "/var/log/lsyncd.status",

    nodaemon = false,

    statusInterval = 1,

    delay = 15,

}


s3sync = {

    maxProcesses = 1,

    onCreate = "[ -f ^source^pathname ] && aws s3 cp ^source^pathname ^target^pathname || true",

    onModify = "[ -f ^source^pathname ] && aws s3 cp ^source^pathname ^target^pathname && aws cloudfront create-invalidation --distribution-id ディストリビューションID --paths ^pathname || true",

    onDelete = "[ -f ^source^pathname ] && aws s3 rm ^target^pathname && aws cloudfront create-invalidation --distribution-id ディストリビューションID --paths ^pathname || true",

}


sync {

    s3sync,

    source = "/home/webadmin/web-root",

    target = "s3://S3バケット名",

}

※上記の網掛け部分を適宜書き換える

(補足)

  • 最初、AWS Transfer for SFTPを使おうとしたけど、CloudFrontのinvalidation込みで動かそうとすると結局サーバが必要になりそうだったし、Lambdaを使うのも面倒だったので、個人的に一番楽な方法で対応
  • この方式に切り替えたサイトはAWSコンソール上で直接S3にファイルアップロードするのは避けるように運用変更が必要(S3とローカルで不整合が発生してしまうので)
  • 本当は git でwebサイト全体を管理して、master更新の都度S3+CloudFrontに反映する感じの方が個人的には良いと思います...ただ、非エンジニアにgitを使わせるのは難儀なので、そうなると安定のFTP(ただし、これから構築するならFTPやFTPSではなくSFTPですが)

2021年3月7日日曜日

Fairy Computer(新しいレトロゲーム機)

Fairy Computer System 80 (FCS80) という新しいレトロ(?)ゲーム機を開発中。

VGSとは別枠です。

VGSが目指した所は、純粋なエミュレーションではなく、アプリケーション・フレームワークによるプラットフォーム共通化でした。規模が全然違いますがUnityみたいなものです。FCS80はVGSと違う純粋なハードウェアエミュレーションによる「仮想ゲーム機」です。

https://github.com/suzukiplan/fcs80

CPUはZ80A互換。

8bit CPUの中で最も拡張性が高いZ80A互換CPUを採用しました。

動作速度はドーピングできなくもないですが、実機Z80Aと同じ(3579545Hz)にしておきましたので、仮に実機を開発する場合でもCPU調達については容易に可能です。

また、音源チップもAY-3-8910互換APUです。

こちらも(Z80Aよりは少し難しいかもしれませんが)一応簡単に調達できると思います。

ただし、PPU(VDP)に関しては既製品ではなく、オリジナルチップ(FCS80-VIDEO)なので、実機を作る場合はFPGA等でエミュレーション?(そっち方面は詳しくないです...)する必要があるかもしれません。

PPUもお手軽に調達できるように既製品を使うことを考えて、最有力候補はTMS9918Aだったのですが、それだとMSXやSG-1000と大差無くなってしまうのでツマラナイ。

ただし、TMS9918Aというと8bit時代のゲーム機のVDP代表格ですが、実のところ8bitでのプログラミングがしやすいかというと微妙です。(そもそもTMS9918Aを最初に搭載したTI-99/4Aは16bit機ですし)

ファミコンのPPUは6502でのプログラミングに特化したものですが、Z80Aのプログラミングに特化したVDPというのは実は存在しないような気がしたので、それならばZ80Aととことん相性の良いVDPを設計してみよう...というのがFCS80を作り始めたキッカケです。

TMS9918A系譜のVDPの何処がダメなのかというと、主にVRAMアドレスの管理が面倒です。TMS9918AのVRAMは16KB($0000〜$3FFF = 14bit)ですが、アドレスアクセスポートは1系統のみなので「2回連続してOUT」という野暮ったい実装が必要な点がイケてない。(実はこの点はファミコンのPPUでも同じです)

そこで、CPUメモリからVRAMをmemory mapする方式を採用しました。つまり、LD系の命令だけで簡単にVRAMを更新したり、読み取ったりすることが可能です。どちらかというとパソコン的なアプローチですね。

(CPU memory map)

AddressMap
$0000 ~ $1FFFPRG0: ROM Bank #0 (Program)
$2000 ~ $3FFFPRG1: ROM Bank #1 (Program or Data)
$4000 ~ $5FFFPRG2: ROM Bank #2 (Program or Data)
$6000 ~ $7FFFPRG3: ROM Bank #3 (Program or Data)
$8000 ~ $BFFFVRAM (16KB)
$C000 ~ $FFFFRAM (16KB)

VRAMがたったの16KBしかありませんが、そのたった16KBで2画面(BG + FG)、スムーススクロール、IRQによるラスタースクロール可能、256スプライト、256色同時発色というファミコンを遥かに凌駕するスペックを実現しています。(実のところまだ2KBぐらい空き領域 = Reserved Area がある)

(VRAM memory map)

CPU addressVRAM addressMap
$8000 ~ $83FF$0000 ~ $03FFBG Name Table (32 x 32)
$8400 ~ $87FF$0400 ~ $07FFBG Attribute Table (32 x 32)
$8800 ~ $8BFF$0800 ~ $0BFFFG Name Table (32 x 32)
$8C00 ~ $8FFF$0C00 ~ $0FFFFG Attribute Table (32 x 32)
$9000 ~ $93FF$1000 ~ $13FFOAM; Object Attribute Memory (4 x 256)
$9400 ~ $95FF$1400 ~ $15FFPalette Table (2 x 16 x 16)
$9600$1600Register #0: Scanline vertical counter (read only)
$9601$1601Register #1: Scanline horizontal counter (read only)
$9602$1602Register #2: BG Scroll X
$9603$1603Register #3: BG Scroll Y
$9604$1604Register #4: FG Scroll X
$9605$1605Register #5: FG Scroll Y
$9606$1606Register #6: IRQ scanline position (NOTE: 0 is disable)
$9607 ~ $9FFF$1607 ~ $1FFFReserved area
$A000 ~ $BFFF$2000 ~ $3FFFCharacter Pattern Table (32 x 256)

グラフィック以外の特徴的な点としては、バンクコントローラがカセット搭載ではなく本体搭載という点です。MSXのメガロムでいうところのASC8方式なので、1セグメント8KBで最大256バンク(つまり、最大2MB = 16メガビット)のROM空間を持つことができます。

あとは、RAMサイズは16KBです。

パソコンだったら多少物足りないサイズ感ですが、ゲーム専用機としてはかなりゴージャスなので、恐らくC言語でも割と普通にプログラミングできるかもしれません。(ちなみにSG-1000やファミコンは標準で2KB)

ただ、飽くまでも「Z80アセンブリ言語でのプログラミングがしやすい」という所を目指していきます。

基礎設計はだいたい出来上がっているのですが、example実装で何本かゲームを作りながら、適宜大幅な仕様変更を交えつつ作っていく予定なので、完成までにはまだまだ時間が掛かりそうです。

2021年1月11日月曜日

湾岸エリア攻略

今回の冬休みは、地元の県(静岡)から帰省禁止令(正確には不要不急の帰省を控えるようにするお達し)が出ていたので、東京で過ごしました。特にやることもないので、自転車で東京をぐるぐる回って過ごしました。

荒川サイクリングロードを使えば、東京の上下の端までの移動が簡単 & 安全にできます。

まずは、江東区若洲にある東京ゲートブリッジへ行ってきました。

というのも、とある位置情報ゲーム(テクテクライフ)で中央防波堤付近へ行く必要があったのですが、中央防波堤には徒歩や自転車では行くことができないので。東京ゲートブリッジを使えば中央防波堤に上陸こそできませんが、結構近づくことができます。(ゲームの方は上陸しなくても近づけば目的を達成できる)

ただし、休暇の期間中、東京ゲートブリッジの歩道は閉鎖されていたので、目的は未達...

※ちなみに、12/31の大晦日に行きました

若洲にはキャンプ場があり、初日の出が良い感じに見えそうな気がするので、キャンパーが沢山居るかと思いきや、目視で確認した範囲ではテントは3つしか無かったです。若洲〜新木場(夢の島)近辺には倉庫とかしかないので、大晦日は完全にゴーストタウンでした。普段は大型トラックが沢山通っているであろう大きな道路がほぼ貸し切り状態だったので、自転車でも車道を安全に走れました。

別の日に、中央区の晴海にも行きました。

コチラもテクテクライフで現地に行く必要があったので。

江東区の湾岸エリアほどではないですが、コチラも中々のゴーストタウン。晴海はそもそも、観光に行くところではないですが、やはり帰省している人が多いのかもしれません。

有明〜お台場方面にも行きました。

晴海と違って観光地ということもあり、まばらに人が居ましたが、「ここは東京なのか?」と錯覚する程度にはゴーストタウンでした。



お台場へ行った目的はレインボーブリッジを渡らないと塗れない部分を塗るため。

レインボーブリッジは車、ゆりかもめ、徒歩の何れかの手段で渡ることができます。なお、自転車の場合、後輪に滑車みたいなものを付けて押していく必要があります。

最後に葛西臨海公園。

コチラも離れ小島(下図)のようなところがあり、現地塗りが必要だったので。離れ小島には普通に橋で歩いて渡れます。

このような感じで東京の湾岸エリア(下図の赤枠で囲っているあたり)を回ってきました。

(主な攻略エリア)

  • 港区(港南・お台場)
  • 中央区(晴海・勝どき)
  • 江東区(有明・豊洲・東雲・辰巳・塩浜・新木場・若洲)
  • 江戸川区(臨海町)

トータルの走行距離はだいたい300kmぐらい。

東京の自宅から実家までの徒歩ルートだとだいたい240kmぐらいなので、実家までの片道分以上の距離を動き回りました。もちろん、1日で全部回った訳ではなく、何日かに分けて自宅〜東京湾岸エリアを何度も往復しています。1日あたりの平均移動距離は50kmぐらい。ミニベロ(小径車)だとこの辺が限界で、もっと行動範囲を増やすにはロードレーサーとかが必要になります。(持ってない)

東京湾岸エリアは、住むにはものすごく不便な場所(そもそも新木場と臨海町には今のところ住宅は無い)ですが、道路が広く、新木場や若洲などのロジスティクス倉庫ぐらいしか無いエリアは休日に車も少ないので、自転車乗りには住心地が良いかもしれません。

ただし、投機的な事情で高級住宅街に担ぎ上げられてしまったので、平民が住めるエリアではありませんが。暴落して安くなったらあの辺への引っ越しもアリかな...と思考を巡らせましたが、どんなに暴落しても足立区や千葉とかより安くなることは無いだろうから、やはりナシかなぁ。でも、豊洲とか有明あたりなら頑張れば都心にも自転車で通えるので、毎日出勤する必要がある日々に戻ったらナシではないかも。

2021年1月7日木曜日

MSXを技術的に振り返る

MSX開発の関係者を匂わせるタイトルかもしれませんが、私は全然関係ない(外野)です。

私はマイコン世代(死語)の人間ですが、実はリアルタイムでMSXは触ったことすら無いです。私が最初に触ったパソコンはPC-9801(16bit機)で、8bit機のMSXは触る機会すらありませんでした。

なので、MSXには全然詳しくないし、思い入れとかも全然ありません。PC-9801だと使えないスプライトが使えたり、PSG音源が標準実装されている点が羨ましいと思った記憶がある程度です。

最近、TinyMSXというMSXエミュレータを開発した関係で、MSXのハード仕様的な部分であれば現役でMSXを使っていた世代の諸先輩方よりも詳しくなりました。そんな客観的視点から「MSXとは何だったのか」を分析してみようと思います。

なお、MSXにはMSX、MSX2、MSX2+、MSX turboRという4シリーズあります。

以降、初代MSXのことは便宜上「MSX1」と表記します。

まず、MSX1のハード構成は以下の通りです。

  • CPU: Z80A互換
  • MMU: 独自システム(スロット)
  • Sound: AY-3-8910
  • Video: TMS9918A

TMS9918Aはテキサス・インスツルメンツ社が開発した画像処理装置(Video Display Processor)です。かなりクセが強いですが、16KBという比較的少ないビデオメモリ(VRAM)でそこそこカラフル(16色中16色を同時発色可能)な映像表現ができます。

TMS9918は元々、1979年にリリースされたテキサス・インスツルメンツのTI-99/4というパソコン(ホームコンピュータ)に搭載するために開発されたVDPです。そして、TMS9918Aは1981年にリリースされた後継機のTI-99/4Aに搭載されました。TMS9918との違いは画面モードにMode 2が追加された点です。(Mode 2は256x3の豊富 & カラフルなキャラクタパターンを表示できる画面モードで、MSX1の市販ゲームソフトの大半がMode 2を使っています)

なお、TI-99/4は最初に16bit CPU(TMS9900)を搭載した先進的なホームコンピュータとして知られています。ただし、変態キーボードを搭載していたり、競合のAppleIIと比べて値段が高かったりといった難があり、1981年までの2年間で2万台以下しか売れませんでした。一方、後継機のTI-99/4Aはかなりヒットして、北米でトータル280万台出荷されました。

MSX1が販売された1983年の時点では、TMS9918Aは既に2年落ちの古いVDPでしたが、TI-99/4Aのヒットにより安価に調達できたものと考えられます。同年にSEGAから発売されたSG-1000にもTMS9918Aが採用されました。

ちなみに、SG-1000と同じ年(というか同じ発売日)に任天堂からファミリーコンピュータも販売されましたが、ファミコンのVDP(PPU)は、TMS9918Aと違い、3色のカラフルなスプライトを同時に64枚(TMS9918Aは単色で同時に32枚)表示でき、1ドット単位の滑らかなBGスクロールができる(TMS9918Aだと8ドット単位のカクカクなBGスクロールしかできない)という、当時としてはとても優れたものでした。

MSX1のCPUは1976年にリリースされたZ80の互換CPU(8bit)です。

そして、PSG(音源)のAY-3-8910は、1978年にリリースされたサウンドチップで、当時のゲームサウンドではほぼデファクトスタンダードの地位だったので、ゲーム機やホビー系パソコンなどに広く搭載されていました。なお、一部のMSXではYAMAHA製のYM2149(AY-3-8910の互換チップ)が使われています。

つまり、1983年に発売されたMSX1は、1976〜1981年ごろに普及した(2〜7年落ちの)古いチップセットが使われています。MSXの基本コンセプトは「ホームコンピュータの標準化」なので、ハード部分は枯れた技術の寄せ集めの方が参入障壁が下がり都合が良かったものと想像できます。

ただし、MSX2(1985年)でだいぶ状況が変わります。

MSX2では、ASCII, Microsoft, YAMAHAがMSX用に共同開発したV9938(通称MSX-VIDEO)というTMS9918A上位互換のVDPが採用されました。

V9938は、カラフルなビットマップ表示(※これはASCIIからのリクエスト)や1行に80列表示できるテキスト表示(※これはMicrosoftからのリクエスト)などが出来る反面、ゲーム向けの機能強化については申し訳ない程度にしか強化されませんでした。

当時のASCIIとMicrosoftはあまりゲームを重視していなかったようです。

グラフィックはかなりキレイになりました。

ただし、ビットマップベースの画像処理には膨大な量のデータ処理が必要です。TMS9918Aは8x8のキャラクタベースの画像処理でしたが、ビットマップベースだとデータ量が単純計算で64倍に増えることになります。しかし、CPUは依然としてZ80(9年落ち)なので、ビットマップベースの膨大な量のデータ処理には向きません。その問題を解決するため、V9938にはコマンドと呼ばれるDMA装置が実装されています。しかし、そもそもデータ処理量が多いのでコマンド実行速度は期待したほど速くありませんでした。そのため、V9938はファミコンよりもキレイなグラフ表示などができる反面、キャラクタベースの画像処理主体のゲーム・グラフィックとしての性能はファミコン(MSX2発売時点で2年落ち)に劣るものでした。実際、ザナックEXと呼ばれるファミコン版ザナックをMSX2へ移植したゲームが存在しますが、処理落ちがかなり酷いものになってしまいました。

MSX2+(1988年)でVDPがV9938からV9958に強化され、横方向のハードウェアスクロールが可能になるなどのマイナーチェンジがされましたが、CPUは依然としてZ80(12年落ち)でした。CPUについてはMSX turboRでR800(16bit)になり劇的に速くなったものの、VDPはV9958に据え置かれており、今度はコマンドのウェイト発生が動作速度upする上でのネックになったものと想像できます。

MSXは世界向けの標準規格を目指していましたが、MSX2の時点で海外のメーカーはほぼ撤退し、MSX2+では日本メーカー3社のみが残り、最後のMSX turboRに至っては日本メーカー1社だけの日本ローカル規格になってしまいました。

MSXの標準化路線自体は正しかったものの、MSX2以降でミスディレクションしているように見えます。MSX1はCPUとVDPのバランスが良かったのですが、MSX2以降の全てのシリーズではCPUとVDPのバランスが常に悪かったという点が目立ちます。MSXはどちらかというと、「ゲーム開発できるゲーム機」という側面が強かったので、ゲーム(ホビー)向けに振り切っていれば、標準規格としてもっと生き長らえることができたかもしれません。

YAMAHAはV9938の開発後、SEGAマークIIIに搭載される315-5124というTMS9918A上位互換(V9938とは別の系譜)のVDPを開発しています。315-5124はMode 4という機能が追加実装され、Mode 4ではカラフル(512色中32色同時発色)なスプライトとBGを表示でき、1ドット単位の滑らかなスクロールも実現できます。更に、Mode 4のBGはV9938のようなビットマップベースではなくキャラクタベースなので、V9938と違いバランスが良い(Z80の処理性能でも制御しやすい)VDPだといえます。Mode 4はファミコンのPPU以上の性能があります。ファミコンだとBGの属性テーブルのビットレイアウトが独特(1バイトで2x2ブロック=4キャラクタ分の属性を設定する複雑な仕様)なのに対して、315-5124はネームテーブルと属性テーブルが各1バイトのシンプルなレイアウトになっているので、315-5124の方がゲームプログラムの開発には適していると思います。

要するに、V9938ではなく315-5124を搭載したMSX (MSX1+?) が欲しかった。

2020年12月24日木曜日

TinyMSX

MSXであってMSXではない謎エミュレータ(TinyMSX)を作ってみました。

https://github.com/suzukiplan/tiny-msx

TinyMSXは、以下のゲームを動かすことができます。

  • SG-1000
  • Othello MultiVision
  • MSX1 (16KB/32KBカートリッジ) ※メガロムは現時点では未対応

オセロマルチビジョンはオマケ。

SG-1000実機を持っている人はレアというか、相当な物好きに限られると思います。1983年7月15日に発売されました。

発売日が任天堂のファミコンと同じ日なので、どうしても比べたくなるのが人の性...

(SG-1000 vs ファミコン)

  • 値段: ほぼ同額だがファミコンの方が200円安い
  • CPU: Z80A vs 6502 ... どちらかといえばZ80の方が高性能
  • 画像処理: TMS9918A vs 独自PPU ... ファミコンの方が表現力が高い
  • 音声処理: SN76489(PSG) vs 独自APU ... ファミコンの方が表現力が高い
SG-1000がファミコンに勝っていた点はCPUのクロックレートだけで、値段、グラフィック、サウンドの面ではファミコンが圧倒的に高性能でした。

    CPUのクロックレートについても、ファミコンのRP2A03(約1.79MHz)の命令の方が全般的に低いサイクル数で命令が実行できたので、SG-1000のZ80A互換(約3.58MHz)が勝っていたとは言い難いです。Z80はパソコン向きに設計されているCPUなので、レジスタが沢山あったり、16bit演算ができたり、ループ命令があったりと機能的に複雑だったこともあり、1命令あたりの消費クロック数が高い欠点がありました。加えて、ファミコンはただでさえシンプルな6502から更にBCDモードの機能を取っ払っています。

    画像処理については、

    • 表示スプライト数: SG-1000は32個 vs ファミコンは64個
    • スプライト色: SG-1000は単色+透明 vs ファミコンは3色+透明
    • 水平スプライト数の上限: SG-1000は4個 vs ファミコンは8個
    • BGの色: SG-1000は横8pxにつき2色 vs ファミコンは1キャラクタに4色
    • BGのスクロール: SG-1000はナシ vs ファミコンはアリ
    • BGのプライオリティ: SG-1000はナシ(スプライトが常に前面)vs ファミコンはアリ

    という具合。

    SG-1000(TMS9918A)が唯一勝っていた点はスプライトのサイズが豊富だったことぐらい(ファミコンは8x8 or 8x16だったのに対してSG-1000は8x8, 16x16, 8x8の2倍, 16x16の2倍)だと思います。

    あと細い所ではファミコンだと0番スプライトの描画検出によりスキャンライン描画タイミングを捕捉できたので、標準機能のみでIRQライクなことができたので、ラスタースクロールが可能です。(IRQについては拡張マッパーで使うこともできました)

    音声については、SG-1000はPSG(AY-3-8910)を若干簡素化したSN76489(矩形波3+ノイズ1)なのに対して、ファミコンは矩形波2+三角波1+ノイズ1+ADPCMで更に矩形波はデューティー比を変更することでノコギリ波に似た音色を出すことができました。

    つまり、用途を「ゲーム」に特化して考えれば、SG-1000がファミコンに勝てる要素はほぼ皆無で、尚且ファミコンよりも微妙にお値段が高いので、この事実だけ見れば「SG-1000はファミコンに負けて当然だね」と思えるかもしれません。

    ただ、SG-1000がファミコンに勝てる芽が一切無かった訳ではないと思われます。

    SG-1000が搭載している装置(Z80, TMS9918A, SN76489)は、独自アーキテクチャで固められたファミコンと比べてゲームを作れるプログラマの人口が(当時は)多かったので、コンテンツ供給力では1983年時点ではSG-1000の方が優位に立っていたと思われます。また、SG-1000とファミコンが発売された1983年には、ASCIIとマイクロソフトが共同で開発したMSXが発売されましたが、MSXもSG-1000とほぼ同じハードウェア構成(Z80, TMS9918A, AY-3-8910)だったことも追い風になったかもしれません。

      ただ、結果的にSG-1000で発売されたタイトルはほぼ全部自社タイトル(一部、オセロマルチビジョンのツクダオリジナル製品もある)で占められていました。当時は現在のようにサードパーティーが参画するという発想自体が無かったのですが、サードパーティーを積極的に取り込む戦略だったら、未来は少し違っていたかもしれません。

      それでも私がSG-1000にめちゃくちゃ思い入れがあるから自らエミュレーターを作った・・・ということであれば美談になるのですが、実はそうでもなく、自作のZ80エミュレータを使ったゲーム機のエミュレータをOSSで作っておきたかったので、ハード構成が単純で作りやすいMSX1 & SG-1000をターゲットにしてみただけだったりします。

      2020年11月25日水曜日

      運動中は消化の良いものを食べましょう

      20km前後のサイクリングにだいぶ慣れてきたので、そろそろ50km超えをトライしてみようということで、三連休の半ばに彩湖を目標にサイクリングしてきました。

      AM10:00に出発して12:00頃に到着。

      到着後、GoogleMapで近所の適当なファミレスを探索。23区内ならランダムエンカウントで問題無いけど、流石に埼玉(朝霞市)でそれは無謀だろうということで。(実際、GoogleMapを使っても結構探索に手間取りました)

      昼食はドリンクバーでジュースを飲みつつピザをチーズ増量&ポテト付きで食べたのですが、これがマズかった。いや、味は美味しかったのですが、これが原因で帰宅後に地獄を見ることになるとは、この時は思いもよらなかったのです。

      約1時間の食事休憩後、朝霞市内を適当に周り、朝霞大橋を渡った所で折返して16:00過ぎに帰宅。

      走行時間は5時間ぐらい。道程の8割ぐらいは荒川サイクリングロード(仮称)だから信号停止とかが無いので、確実に平均時速10km以上は出ていた筈(もっと速いかも?)だから、恐らく50km以上走った筈です。(次はちゃんとサイクリングコンピュータとかを使おう...)

      初めて50km以上走ったものの、足は思っていたよりも筋肉痛にはならなかったので、もっと先まで行けたかも。ただし、何故か腕が筋肉痛になりましたが。

      筋肉痛は想定内なので問題無いのですが、帰宅後から謎の腹痛がして気持ち悪い。

      何だこれ?

      まぁ、動けないレベルではないし、時間が経てば自然と治るだろう...と、早め(21:00頃)に就寝したのですが、腹痛がひどくなるばかりで寝付けず、24時を過ぎたあたりで「これ、危ないヤツではないか?」と思い始めました。

      想定外の体調不良というのは中々怖い。

      ネット上の医療情報を漁って「激しい運動をすると内蔵がぐちゃぐちゃになるから補給は消化を良いものを」みたいな記事を見て「あ、昼食のピザがアカン奴だったのでは?」と気づく。幸い手元に緩下剤(夏に受けた健康診断で貰ったヤツの残り)があったのですが、先ずは薬には頼らず、民間療法で何とかすることにしました。

      ネットで「便秘に効くストレッチ」みたいなものを参考にストレッチしたり、DAKARAを飲んでみたり、タバコを吸ったり色々試したAM2:00過ぎ、ようやく変わり果てたピザ(宿便)との再開を果たし、無事腹痛が収まりました。

      うーん、こわい。

      じゃなくて、運動する時の補給には気をつけましょう。

      恐らく、今回のように中間地点で補給する場合、ゼリー状のヤツとかが良さそう。ファミレスやファーストフードに寄るなら若干のクールダウンを挟んだ後のタイミングで。固形食を摂る場合は咀嚼回数を普段の倍程度しつつ、すぐに動かない(長めに休憩する)ようにすれば問題無かったかもしれない・・・まぁ、何の医学的な根拠もないカンですが。問題が発生したら原因を特定して対策を実施、治ったら再発防止処置を講じるといういつものやり方。

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

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