July 2009 Archives

私は普段ほとんどゲームをしない(別に嫌いなわけではない)のですが、ふと見つけてダウンロードしたゲームにちょっとはまっています。 東方プロジェクトという方々が作られているゲームで、東方何某というシューティングゲーム(の体験版)です。

このゲーム、当然私は一番やさしいモードでしかまともにプレイできません。 でも面白いと思ったのは、「敵の弾が画面一杯に出るけど、避けられる」ように作ってある点です。 当たり判定を狭く設定してあるのと、ボス戦など強い敵の場合には自機の近くでは弾のスピードが落ちるようにしてあるので、落ち着いて行動するとかわせるのですね。 とは言っても常に、というわけではないですし、未だに体験版をクリアすることもできてませんけど。

で、ちょっとだけ作ってみたいなどと思ってしまいました。 もちろん、ストーリーやキャラデザインやらゲームバランス調整やら、能力と根気のない私にはとても無理です。 私が思ったのは、ゲームのアルゴリズムのほうの話です。

その昔、PC-6001などでゲームを作りまくっていた頃があるのですが、不思議とシューティングゲームをほとんど作った記憶がありません。 アクションパズルやシミュレーション、ロールプレイングゲームみたいのは結構作ってましたが。

今考えてみると、どうも「弾を飛ばす」のが苦手みたいなのです。 三角関数も知らなかった当時、任意の角度に複数の弾を飛ばす、というのがものすごく難しく見えました。 また、敵の動きのアルゴリズムをどうやったらパターン化できるか(e.g. 編隊飛行)、ということも知りませんでした。 いろいろ挑戦したけど挫折。 以来トラウマになったみたいです。

んで何となくWebを彷徨っていたら、国立情報学研究所(NII)のサイトにシューティングゲームの敵機攻撃弾発射アルゴリズムに関する考察 などという論文を見つけ、ちょいと驚きました。 確かに、Entertainment Computingは私がCMUにいたときにひとつの分野として確立していましたから、何も不思議はないのですが。

でも今見ると、たまにはこういうのを作るのも楽しそう、と思えてきます。 もちろんターゲットマシンはPC-6001。 まぁ、自機や敵機の動きを作ったり、弾を飛ばすことなどで満足してしまい、ゲームとして完成させることは無理でしょうけどね...。

ちょいと画像やサウンドのトランスコードをやりたいと思いました。 ていうか、これまでも結構やってましたが、これまでこの手のものはCでバイト入出力で組んでいました。

CやC++で組むときも、Windowsなどのライブラリを使えば早いのでしょうが、UNIX文化というかJava文化に慣れきっているので、クロスプラットフォームにならない作り方はあまりしたくないのです。

で、クロスプラットフォームならと、ためしにJavaでやってみました。 Javaは仕事、というイメージがあるので、普段はあまり趣味で使いたいとは思わないのですが。

すると、既にAPIがそろいまくってるんですね。 ヘッダ解析からバイト単位で全部組んでいたのが嘘のようです。

サウンド関係はjavax.soundパッケージにそろっています。 標準パッケージのみだとmp3などのコーデックは入っていませんが、コーデックさえあれば同じAPIで使えるのが便利です。 たとえば、次のようなコードでアクセスできます。

AudioInputStream ais = AudioSystem.getAudioInputStream(new File("foo.wav"));
byte[] buf = new byte[ais.getFormat().getFrameSize()];

int bytes = ais.read(buf);

これで1フレームを取得できます。 フレームサイズとは、(1サンプルのバイト数) x (チャネル数)のことです。 たとえば、よく使う16ビットステレオであれば、2 x 2 = 4バイトということになります。 なお、フレームサイズ単位で取得する必要があります。

また、画像関係はjavax.imageioパッケージを使うと、やはりフォーマット非依存で似たような感じになります。 画像の各ピクセルに処理をしたいのであれば、たとえば以下のようにできます。

BufferedImage image = ImageIO.read(new File("foo.jpg"));
for (int y = 0; y < image.getHeight(); y++) {
  for (int x = 0; x < image.getWidth(); x++) {
    int rgb = image.getRGB(x, y);
    // ...
  }
}

もちろんこれは簡単な例で、さまざまな操作が可能です。

さて、問題は動画です。

調べてみましたが、Java Media Framework (JMF)というのがあります。 しかし、Java 2の標準APIには含まれていません。 また、最新のリリースが2003年ごろで止まっており、サポートしているフォーマットもあまりありません。 APIも貧弱です。

JMFのPerformance Pack (プラットフォーム固有のネィティブコードを使って高速に処理するライブラリ)をインストールしようとしたら、パソコンが固まってしまってにっちもさっちも行かなくなりました。 というわけで、ちょっと手を出しかねています。

ffmpegあたりと組み合わせて、(動画)->ffmpeg->(画像+サウンド)->ffmpeg->(動画)とすることも考えたのですが、いったん画像とサウンドを完全分離してしまうと、合わせるときにずれることがあるのであまり積極的にやりたい方法ではありません。

以前Cで組んでいたときは、このずれを心配したので、ffmpegで動画を変換し、フレーム単位で処理していました。 しかし、これをやりたい場合はjavax.imageioや、特にjavax.soundの恩恵をあまり受けられません。

う～ん、なかなかうまくいかないもんですね。 今のところは、ffmpegのフロントエンドのJffmpegあたりを使うしかないのですかねぇ。

ご存知のとおり、Intel MacはBasic Input/Output System (BIOS)の代わりにExtensible Firmware Interface (EFI)を使用しています。 そのため、同じCPUやチップセットを搭載していても、このままではWindows PCにMac OSを載せることはできません。

EFIは仕様策定にIntelが大きくかかわっており、Windows系のPCもいつEFIになってもおかしくないのですが、なぜか未だにほとんど実装されていません。

以前お伝えしたように、USBベースでEFIを実現するEFi-Xという製品があります。

この改良モデルが発売されているようです。

サポートされるプロセッサはLGA 755ベースのCore 2 ExtremeからPentium Dual-Core、Celeron、Atom、Xeonと多岐に渡っています。 ただ、現在のところAMDのプロセッサには対応していません。

また、マザーボードはGIGABYTEおよびDFIの一部製品、グラフィックカードもATIおよびNVIDIAの一部製品と、必ずしもどのPCでも動かせるというものではありませんが、対応製品を持っているならば人柱になるのも面白いかもしれません。

続きです。 西田さんからBELUGAのアダプターの回路図を参考にせよとの指摘があったので、それに習って調べています。

まず、BELUGAのアダプターは次のように信号を作っています。

CS = (RAS2 and EXCAS) or (MREQ & デコード済みアドレス)
OE = DRD2 or CS3

なお、全部負論理である点に注意してください。

私のカードの論理は次のように修正しました。

CS = EXCAS or (MREQ & デコード済みアドレス)
OE = DRD2 or RD

これで動かしてみたことろ、テキストモードのページ1とページ4がちらついた状態で表示されました。 ただし、スクリーンモードを4などにすると画面が乱れます。

どうも、ページ1にはページ1とページ3が、ページ4にはページ2とページ4が混じって表示されているみたいです。 その証拠に、画面左下のページ番号がちらついて両方表示されており、たとえばページ3のスクリーンモードを変更するとページ1の表示に影響しています。

BELUGAのカートリッジでCS3を使っているのはROMエリア読み出し用だと思うのですが、DRD2のみでRDを使ってない理由はよく分かりません。 DRD2はVRAM DMA用のRD信号ですが、通常のメモリアクセスでもアサートされるのでしょうか?

CSを作るのにRASとのandを取っているのもよく分かりません。 SRAMですから、CASだけ見れば十分じゃないかと思っているのですが、タイミング的にRASも見ないとネゲートのタイミングが遅すぎたりするのかな?

CS2/CS3などを扱うROMエリアがメモリデコードだけでアクセス可能になるかどうかも気になりますが、その前にRAMエリアももう少し調査・実験が必要です。

(20 July 2009追記)

CSの入力をEXCASの代わりにRAS2に変更してみると、まったく画面が乱れたままなので、やはりEXCASのほうが「近い」のですが、andを取らなければならないのかもしれません。

と思い、EXCASとRAS2の両方を使ってみました。 つまり、

CS = (RAS2 and EXCAS) or (MREQ & デコード済みアドレス)
OE = DRD2 or RD

であり、ほとんどBELUGAと同じです。 しかし、何も症状が変わりません。 画面は乱れたままです。 RAS2の入力をはずすと元に戻ります。 すなわち、ちらついた状態になります。 何で...???

もう降参。 ダレカタスケテ...;-(

ちなみに表示の様子。

ちらついてるのが分かるでしょうか?

少しづつ原因を特定しようと頑張っています。 今のところ、明らかになっているのは次のような動きです。

• 起動時、本体は32kBとして認識している。これは、BIOSで以下のようなロジックを実行することで判定している。

  ld      hl, 0xbfff
  ld      b,(hl)
  ld      (hl),a
  cp      (hl)
  

  ちなみに0xbfffは拡張RAMの最終アドレス。
• スクリーン1(0x8000-0x83ff)およびスクリーン4(0xa000-0xb9ff)の表示は同じように乱れている。
• スクリーン1のアトリビュートエリア(0x8000-0x81ff)やテキストエリア(0x8200-0x83ff)をpeekすると内容は正しい。
• スクリーン2(内蔵RAM)を表示した状態でプログラムを入力したり実行したりできる。すなわち、0x8400からのメモリを正しくアクセスしている。
• スクリーン1または4でキー入力をするとかなりの確率でリブートしてしまう。
• screen 4,4を実行するとかなりの確率でリブートしてしまう。

ここから言えることは、以下のようなことです。

• SRAMはほぼ正常に動作している。
• VDGからのDMAで正しいデータを読めていない。現在はDRD(拡張コネクタ3番ピン)が0になるときにSRAMからのCSおよびOEをアサートしてますが、それでは足りない?
• VRAMに書き込みをするとリブートしてしまう。

DMA関連の不具合は、ハードウェアに起因した現象なので、ちょっと困り果てています。

もともと、PC-6001の拡張RAMはDynamic RAMを想定しているので、ひょっとすると、DRDのみでSRAMをリードにしてしまうのが原因なのかも。 DRDのタイミングのみでSRAMをアクティベートしていることで、何か他の信号との関係でデータバスがコンフリクトしていることが考えられます。 もしそうだとすると、RAS and/or CASのアサートも見なければいけないのかもしれません。

そうなると、さらにCPLDに入力しなければならない信号が増えてしまいますね...。

Discrete logicに外出しにするにしても、DRDとRDはand(7408)で、RAS/CASはor(7432)なので、ひとつのチップで処理できません。 まぁ、74139を使ってデコードするという手はありますが、手元にあったかな?

続きです。 ページ1(0x8000-0x83ff)およびページ4(0xa000-0xb9ff)の画面は乱れるものの、なんとなく動いていたSDアダプタですが。 たまに入力を受け付けなくなって暴走するなど、やはり不安定です。

どこか結線の問題だと思っているのですが、正直調べるのはかなりの苦行です。 回路図と睨めっこしながらハーフピッチのコネクタにショートや断線がないかどうか一本ずつ調べる必要があります。

なまじジャンパが結構這っているので、それも含めて丁寧に追いかけなければいけません。 ジャンパはUEWなので、断線ならまだしも結線の際に熱でどこかショートしてたとしたら、発見するのは相当厄介です。

これまでいろいろ作って一番経験したデータバスの誤配線はなさそうです。

また意外にも、パッドとラインの間の隙間が非常に狭いところなどには今のところショートなどは見つかっていません。

CPLDやAVRのプログラミングを行うのも特に問題は起きていないので、電源周りも大丈夫そうです。

う～ん、やはり地道にやっていくしかないのか...。

続きです。

回路に一箇所誤接続がありました。 データバスの部分でしたので、動かなかったのも納得です。

とりあえず似非ROMは後回しで、外したままですが、早速直して動かしてみると...画面が真っ白。

よく調べてみると、キーを受け付けますし、プログラムを入力したり実行したりできます。 プログラムを入れて0x8400近辺のアドレスをpeekすると、ちゃんと入っているのです。 ところが、スクリーン1と4が真っ白で、2と3はちゃんと出力されます。

それで気づいたのですが、6847からのDMAって、MREQまたはRDを使っていない?!

またしてもオマエカー!! VDG!!

これは気づきませんでした。 ええと、6847からのリード要求はコネクタ3番かな? 唯一残っているCPLDに入力して、CSのロジックを変えてみました。

...動かない。

よく考えてみたら、SRAMのRDがアクティベートしていないようなのですから、いくらCSをいじったところで読み出しができるわけがありません。 ということは、現在拡張コネクタからダイレクトに入力してしまっているSRAMのOE信号自体に細工をする必要があるということです。

たったAND1個ですよ。 でも、CPLDのI/Oがたった1本(SRAM OE用出力)だけ足りない...。 そのために08をつけるのは馬鹿馬鹿しいし、パターンもありません。

「こ...こうなったら、醜くてイヤだが、大猿に変身してアドレス線を1本削ってぶっつぶしてやる......!!」

で、A4を削ってやってみました。 白い画面ではなくなりましたが、ページ1と4が乱れまくっています。 ちなみに、以下のようなロジックです。

  OE <= RD and DRD;

  process (MREQ, Address15, Address14, INIT, WR, DRD)
  begin
    if DRD = '0' then
      CS <= '0';
    elsif MREQ = '0' and Address15 = '0' and Address14 = '1' then
      if INIT = '1' or WR = '0' then
        CS <= '0';
      else
        CS <= '1';
      end if;
    elsif MREQ = '0' and Address15 = '1' and Address14 = '0' then
      CS <= '0';
    else
      CS <= '1';
    end if;
  end process;

DRDは拡張コネクタ3番、OEはSRAMへ行っています。 もう、DRDがアクティベートされたら無条件でSRAM READにしている感じです。

でも、ちゃんと動きません。 う～～ん、あと何が足りないんだ??

続き。SDアダプタですが、まだ動いていません。

tiny2313をつけた状態で電源をつけると暴走しているので、データバスがコンフリクトしているのではないかと思います。 tiny2313はROM代わりですので、とりあえず外してしまえば単なる拡張RAMカードとして機能するはずなのですが、外すと何も起こらず普通に起動し、内蔵の16kBしか認識されていません。

というわけで、CPLDがうまく動いていないのではないかと思います。

たいしたロジックを入れているわけではないし、ISEではフィッティング含めエラーも出ません。 Timing constraintsは何もかけていないのでwarningが出ますが、たいした問題ではないでしょう。

ロジアナがあるとはいえ、回路上で実動作を確かめるのはとても大変です。 そのため、Behaviour modelをベースにシミュレーションをしているのですが、今のところ特に問題らしいところも発見されていません。

とりあえず今のソースを貼り付けておきます。

拡張バスからの信号は、アドレス線、データ線とRDおよびWRは直接SRAMに接続し、CSのみ次のようにCPLDでデコードしています。

  process (MREQ, Address15, Address14, INIT, WR)
  begin
    if MREQ = '0' and Address15 = '0' and Address14 = '1' then
      if INIT = '1' or WR = '0' then
        CS <= '0';
      else
        CS <= '1';
      end if;
    elsif MREQ = '0' and Address15 = '1' and Address14 = '0' then
      CS <= '0';
    else
      CS <= '1';
    end if;
  end process;

• 初期化時(AVRから^INITが入る)の0x4000-0x7fffへの読み込みはインアクティブ
• 初期化時の0x4000-0x7fffへの書き込みはアクティブ
• 0x8000-0xbfffへのアクセスは常にアクティブ

ひょっとしてCPLDにクロック供給とかいるのかなぁ。 クロックとして使われるピンも普通のI/Oにしちゃってますが。

あ、それともSRAMにCS以外の信号線を垂れ流し続けるのって無謀? データシート上ではCSさえインアクティブにしておけばデータバスはHigh-Zになって楽なのでこんな感じにしたんですが。

先週基板ができたので、今日はジャンパを通しました。 およそ30本。 面倒ですが、全部手配線に比べたら圧倒的に楽です。 ちなみにUEWを使って半田面に配線したので、部品面は未だにスッカスカです。 ISP用に背の高いコネクタをつけたくらい。

プログラミングはCPLD、tiny2313、mega88の3種類に必要です。 デバイスへの書き込みはこれだけのために用意してある古いノートパソコンを使います。 タダでもらったVAIOで、シリアル&パラレルポートを持っています。

なおこれ、液晶のヒンジが折れています。 ありあわせのネジで直しても直しても折れてしまうので、スピーカーに寄りかかった状態で使っています。

CPLDは特に問題もなく終了。

tiny2313が、どうしてもDevice connection failedでうまくいかない...。 RS-232Cを疑ったり書き込みデバイスを変えたり、いろいろしてもなかなか見えず、仕方ないので試しに別のチップでやってみたら...できた。

見事にババ引いちゃったみたいです。 その間、電源取りに使っていたFT245Rのボードを壊してしまったみたいです(泣)。

mega88のほうは、まだプログラムのほうが古いままで、新しいアダプタに対応していません。

明日の引越し荷物到着の準備をしなきゃいけないし、今日はもう疲れたので、こちらは明日以降にしましょう...。

それでも、面倒なハードウェア部分はおおよそ終わったので一段落かな。

フラッシュメモリベンダはここのところずっと赤字ですが、生産調整も行っているので以前に比べ価格の低下速度は鈍化しています。 それでも、現在主流のSDHCメモリカードは最大容量でだんだん底値に近づいてきているようです。

現在の単価は16GBで180円強/GB、32GBで200円強/GBです。

SDHCが32GBどまりである理由、次世代であるSDXCメモリカードの規格が不甲斐ないことなどを以前お伝えしましたが、大量生産により安価になること自体はユーザにとって歓迎ですね。

ちなみに、私の持っている一番新しいパソコン(Toshiba Portege R600-108)は、なぜか手持ちのSDHCカードを認識してくれません。 しょぼ～ん。

私はいつも日本に行ったときに基板やらパーツやらを買ってくるのですが、当然イギリスでもこれらのものを手に入れることは可能です。 ただ通販ベースのものが多く、秋葉原のように手にとって選べないことが多いのと、慣れの関係で、日本で買っています。

こちらでメジャーなパーツショップといえばMaplinですが、見てみるといわゆるポジ感光基板も扱っていました。 価格は全般的にサンハヤトのものよりは安いようです。 たとえば、Fibreglass(ガラエポに相当すると思われる)100x75mmサイズの両面基板で1.73ポンド。 日本だったら1000円弱します。

ちなみに銅箔が施された生基板はCopper-Clad Board、感光基板はPre-Sensitised Copper-Clad Boardです。

商品情報を見ると紫外線で感光させるようなのですが、どのくらいの波長かなどはよく分かりません。 UV-EPROMを消去するのに使うものでよければそんなに問題はないですね。

また、エッチングのあとに再び感光するように説明されています。 ちょっと扱い方が違うのかもしれません。

以下抜粋:

The PCB should be exposed using our UV exposure box and a circuit overlay transparency. Exposure time will be from 8 to 15 minutes. Mix together 0.5 litres approximately with one teaspoonful of sodium hydroxide (available from most chemists) and pour into a tray (CH38R). Gently rock the exposed PCB in the tray until the unwanted photo resist is dissolved away. Etch the board in a bath of ferric chloride and after rinsing, expose the PCB in the UV box for a further 10 minutes. Wash off all the remaining etch resist in a tray of sodium hydroxide solution.

サンハヤトの現像液はメタ珪酸塩ですが、こちらは水酸化ナトリウム(sodium hydroxide)を使うようです。

でもちょっと面白そう。 Maplinは店舗自身はたくさんあり、こういった商品の在庫を持つ店も時々存在するので、そのうち試してみたいものです。

先日日本でジャンク漁りをしました。

私の狙いはもともと、XTバス用のカードなんですが、1～2年前にはそこそこ見かけたカードも今やほとんどありません。 ていうか、ISAのカードですら逆にプレミアムがついているのか、高いのです。

特に、8ビットでのビデオカードが狙いだったのですが、ちょっと変わったカードを見つけました。 最初ビデオを含むマルチファンクションカードだと思ったのですが、どうも違います。

ALiのチップがついていて、AMI BIOSやらRTCが載っている時点で怪しさ満開なのですが、調べたらやっぱり違いました。

これはいわゆるSingle Board Computer (SBC)で、組み込み用途などでよく使われているもののようです。 ISAインタフェースに準拠しているように見えますが、実際には既存のPCにインストールするのではなく、特別のバックパネルに入れて使います。

今風に言えば「ブレードサーバ」ですかね。:-)

右上にAT電源コネクタがついていることからも分かるように、これ単体でもコンピュータとして機能します。

型番はSBC-456。シリーズにSBC-456Eというのもあって、これはEthernetがついているのですが、残念ながらそれはありませんでした。 ただ、右のほうに空きパターンは用意されていて、Realtekの8029とパルストランス、いくつかの受動部品を実装すれば動くみたいです。 そう、8029。 PCIバスなのです。 見たまんまISAバスの顔をしたPCIベースのコンピュータです。 ただし規格の関係で、下にある大きな2つのコネクタにマウントできるのはPC/104準拠、すなわちISA準拠のモジュールのみとなります。

CPUはAMDのDX5-133(486互換、133MHz)で、ALiの2つのチップは想像通りチップセット。 基本的なI/Oはすべて装備しているので、電源、メモリ、ディスクをつけてキーボードとモニタに接続すればパソコンとして動作します。 AT電源なんてもう持ってませんが、+5V(3A)と+12Vで動作するようなので、ハードルは高くないですね。

パソコンとしてのスペックは以下のとおりです。

• AMD DX5-133 CPU
• L2 cache 128kB onboard
• C&T 16550 with display memory 1MB onboard (2MB optional)
• Memory up to 64MB with two 72-pin SIMM sockets
• 32-pin DIP SSD up to 144MB
• EIDE, FDD, RS-232, RS-232/422/485, IrDA

左下のソケットにはフラッシュメモリ(ROM互換)が挿せるようになっていて、ディスクレスシステムを構築することもできます。 また、LCDコントローラが内蔵されていて、いくつかのLCDを直接ドライブできるようです。

ちなみに、左端のメモリは私が持っていたジャンクを挿しています。

買ったときは部品取りに使うつもりだったのですが、これはこれで楽しそうなので、このままそのうち活用してみようかと思います。

あ、ちなみに価格は840円でした。 ネットで調べると今でも現役で売っているところもあるみたいですね。 数100ドルと、結構高いですよ。

ここんところ、SourceForgeへのCVS接続がうまく動かない障害にずっと悩まされていて放置プレイだったのですが、久しぶりにContikiのメンテナンスをはじめてみました。 一応私は、Z80全般およびPC-6001部分のソースが担当になっています。

ていうか、えらいコードが変わっていて、ついていけない...。 まぁ、メーリングリストもちゃんと読んでいるわけではないんですが。

しかし、そんなことより問題は、SDCCがバージョンアップ(2.9.0)したことにより、今までなら通っていたと思われるコードが通らなくなってしまったことでしょう。 なんか、開発時間の半分以上はSDCCのおかしな挙動の解析とその回避に費やしているような。

最初に動くようになるまでは楽しいのですが、こういうメンテナンス作業って苦痛なんですよね...。

P6絡みののりさんが、ROM乗せかえ(実際にはエミュレータ上のBIOSイメージ入れ替え)によるフリーのPC-6001実行環境を開発しています。

私も以前、実機のROMを外して別のROMやRAMに変えられるのではないかと妄想していましたが、それをエミュレータ上でやってしまおうということですね。

現在のエミュレータでも、ROMイメージファイルの入れ替えはできますが、RAMにできたらいいなぁ。 そうしたら、SDカードから似非ROM(別に本物のROMでもよいが)で起動して、CP/MやらUN*Xもどきやらを作れそう。 もちろんContikiも動かしやすくなります。

おそらく実機に実装されているROMを外してしまえば、拡張カードに積んだROMやSRAMが動くと思うので、あながち夢物語でもないような気がしています。 PC-6001mkII以降の場合は最初から64kB RAMが実装されているので、そちらでやったほうが早いかな? でも中身しらないんだよな～。

などと思っていたら無性にOSのソースが読みたくなって、ELKSやらMINIXやらのブートアップソースを眺めちゃったりしてます。 久々にx86のアセンブリソースを見ました。 これでも昔はPC-9801(初代)内蔵のワンラインアセンブラでゲーム作ったりしてたんですョ。

Z80ベースのOSなら「まずCP/Mを読め!」と言われそうですが、Intelニーモニックのオールアセンブリなので、読むのが面倒なこと、もともと商用ライセンスのものであること、設計が古いということで、ちょっとスキップです。:-p

x86(というかIBM PCおよび互換機)ではBIOSがソフトウェア割込み(INT 13hなど)によって基本機能を提供していますが、Z80系だとRSTを使うのがいいのでしょうね。 CP/Mのように常に0番地をRAMにしろというのも微妙ですが、64kB空間を確保してRSTベクタを活用すれば、他機種への移植性も高まるでしょう。 さすがに割り込みモード0を使った機種はないと思いたい...。

BIOSといえば、LinuxなどではROM BIOSに依存するのは最初のブートアップのときだけです。 最初の一部分はどうしてもBIOSに依存しなければならないのですが、そのせいで逆にブートアップシーケンスがとてつもなく面倒なことになっています。 Linuxカーネルのbootsect.Sやsetup.Sを見ると苦労の跡がしのばれます。

SDカードアダプタへのI/Oがコールドスタートのできるだけ直後に開始できれば、機種依存のROM BIOSを可能な限り小さくできます。 そうすれば、読み込むカーネルが機種依存になるとしても、ただのFAT上のファイルなので移植やメンテナンスが多少は楽になるかもしれません。

今のSDカードアダプタを動かしたら、試してみたいものです。

これまでのフライトで、ANAの国際線運賃クラスがかなり判明しました。

運賃が高い順からリストします。

• F: ファーストクラス運賃

• C: ビジネスクラス普通運賃
• D
• J
• Z: ビジネスクラス割引運賃

• Y: エコノミークラス普通運賃
• E: ここまではマイル積算率100%
• B: PEX運賃, マイル積算率70%, ビジネスクラスにアップグレードができる最低レベル
• (この間のクラスは不明)
• T: 包括割引, マイル積算率50%

• Y: エコノミークラス普通運賃
• E: ここまではマイル積算率100%
• B: PEX運賃, マイル積算率70%
• M
• S: ビジネスクラスにアップグレードができる最低レベル
• H
• W
• L

• Y: エコノミークラス普通運賃
• E: ここまではマイル積算率100%
• B: PEX運賃, マイル積算率70%
• M
• S
• K: ビジネスクラスにアップグレードができる最低レベル
• (これ以下のクラスは不明)

ビジネスクラスへのアップグレード可否は、マイルまたはアップグレードポイントを使ってアップグレードをする場合を指します。

それぞれの運賃クラスごとの料金は季節ごとに固定されています。 ただし、クラスごとの提供座席数は不明です。 エコノミークラスでは、通常は安い運賃クラスから埋まっていきますから、欧米・アジア地区発の場合は"L"クラスからなくなっていくでしょう。 でも、片道アップグレードしたい場合などは、うまくアップグレードしたいほうを"S"あたりで取れば、比較的安くアップグレード権を得ることができることになります。

ただ、アップグレードも運賃クラスの高いほうに優先度があるようなので、"Y"や"E"ですぐにビジネスクラスが取れても、"M"や"S"だと空席待ち、とかいうこともあるようです。

一応、この情報は知りうる限りですが、無保証ですので悪しからず。

SDカードアダプタ、まだやってます。 先日失敗した感光基板作成、日本で基板を買って戻ってきたので、再挑戦です。

今回は出力11Wの蛍光灯を使いました。基板との距離は10cmちょっとくらいです。 10分ごとに蛍光灯の位置をずらしつつ、感光時間は1時間弱行いました。

感光の様子。

現像の結果。 一部ベタ部分で基板にインクがついてしまったところは感光剤がはがれてしまいましたが、おおよそ良好な結果になっています。

感光剤がはがれた部分はレジストペンで修正をかけて、15分エッチング。 エッチング液はおよそ40～45度。

今回はきれいにできました。

穴あけは、基本が0.6mm、ICソケット(1箇所)および太目の線を通す部分は0.8mm、レギュレータは1.0mmです。

んで、部品実装を開始しました。

部品面のエッジコネクタをどうするのか、いまさらになって問題になりました。 EジスPenを使うつもりだったのですが、摩擦に弱いんですよね。

仕方ないので、例により(?)ファミコンカセットのジャンクから毟り取ったコネクタを接続。 必要部分だけとはいえ、40本近くの配線量になりました。 結構面倒だしやりにくい。 しかも何度も再利用しているのもあって、出来が汚い...。

で、今はこんな感じです。

ボードが大きくてスカスカに見えるかもしれませんが、片面基板のため、配線は右側の銀色の部分を除いてかなりびっしりです。 配線間隔は50mil(1.27mm)です。

そのため、100mm x 150mmの基板を使いました。 75mm x 100mm両面でもいけるかと思ってアートワークしてみていますが、せっかく両面なのだからジャンパを飛ばさずにと思うとかなり難しいです。

主要な部品はつけ終わりましたが、今回の片面基板バージョンではジャンパも結構飛ばさなければいけないので、のんびりやります。