[SxSI] X68000 の SPC のレジスタの説明を読んでると セレクションフェーズとリセレクションフェーズの前に アービトレーションフェーズを実行するかどうかを 指定するビットがあった。 なんだ、アービトレーションフェーズって SCSI 的にも 実行しなくてもいいのか。 だったら問題ないんちゃうかなあ。
# だから SxSI ってのがあるくらいだから問題ないんだってば(笑)
SASI ハードディスクから指定されたセクタを読み込む サンプルプログラムを読んでみた。 なんかとっても簡単そう。
[DMA] ほんとは開発日記なんだけど、そんな大それたことではないから お遊び日記っていう名前にしてるんだけど、 どう見ても InsideX68000 の読書感想文的な気がする今日この頃。 まあコード書く時間なくて Inside を読む時間だけはあるので 無理もないか。早く EX68 が 68030 をサポートしてくれないかなあ(笑)。 そしたら電車の中でノートPCで NetBSD/x68k on win...。
ただいま DMA の動作をお勉強中。
[etc] 関係ないけど RTA50i で ISDN を導入したので やっと NetBSD/x68k がネットワークにつながった。 めっちゃ快適。FLET'S してーー。 Human68k が TEL2 ポートにつながってるので LAN にはならないんだよね...。 NetBSD/x68k 用に Neptune-X 作ってさらに Human68k の SLIP ドライバ書けってか...。
[SxSI] HDC の遊び方は分かったんだけど、結局 scsipi とのリンク方法が分からなひ。 ドキュメント書いてよー。しくしく。
[ADPCM] なので、 ADPCM のデバイスドライバ書いて音を出そうと思った。 こっちは /sys/dev/audio_if.h 見ると SCSI よりはなんとかいけるかなーと思った。 でも PCM → ADPCM 変換って推測情報しかないのよね...。 /sys/arch/x68k/dev/{adpcm.c,bsd_audio*} って どれくらい obsolate なんだろう...。
余談だけど NetBSD/x68k (68030/30MHz) で bladeenc で mp3 をエンコードしてみた。 5分の曲が6時間たっても終らなかった...。 一体どれだけかかるんだろう。
[memswitch(8)] memswitch(8) コマンドの usage に typo を見つけたことに 端を発して、クラス名のみで表示する修正をして みのうらさんに commit してもらった。 乗りかかった舟なので、boot.device=inscsi0 の 書き込みができるようにする修正を作ってる。 コードは書けたけどコンパイルはまた明日。 たぶん動くと思うけど、それ以前に SRAM での 起動デバイス設定あたりがよく分かってないのが 悲しいところ。
[memswitch(8)] コンパイルしてみたけど、いまいち不調。 やっぱ分かってないものをてきとーに修正して すぐに動くなんていう都合のいい話はないやなあ。 まあ簡単そうだから時間のある時に見れば すぐ直りそうだけどね。
[memswitch(8)] 今日も memswitch みてみる。 つーか1日1時間じゃプログラムは書けねえ。
[Neptune-X] おうちに RTA50i があってさらにもうじき先輩から i386 マシン (P5/133MHz くらい?) が 頂けるとなると、うちの X68030 に Neptune-X がないのは かなりつらいので、自作することを決意した今日この頃。
[memswitch(8)] memswitch -w boot.device=inscsi0 完成。
こんな感じ。思いだしながら書いてるんだけど。# memswitch -w boot.device=inscsi0 boot.device -> 0xfc0000 boot.device -> ROM # memswitch boot boot.device=ROM boot.romaddr=0xfc0000 boot.ramaddr=0xed0100
[SxSI] らちがあかんので電車の中で sys/dev/ic/mb89352.c (SPC) の ソースを読んでみた。 上位とのインタフェースは なんちゃらcmd と sched だけみたいね。 コマンド渡されるのとスケジューリングする(?)のと。 メインは割り込み処理なのね。 要は cmd, sched, intr の3つが上位とのインタフェースと 考えて現在のフェーズと上から渡されたコマンドと SCSI バスの状態とをみて intr でいろいろしろってことなのね。
だいぶん分かったけど、ドキュメント書いてよ...。 scsi(9) とかさ...。 なんでソースから全体像を把握せにゃならんのじゃ。 でも結局 source code is my friend って感じが...。
[ADPCM] SASI はとりあえず実機が用意できないと何もできないので おいとくとして、音でも出してみることにする。 なんでも簡単に言うなあ...(笑)。
[ADPCM 改め okiadpcm] とりあえず okiadpcm0 いりカーネルが起動するようになった。 中身まったくないんだけどね。
こんな感じ。 てゆーか、ここまでは猿でもできるんだけど(笑)。okiadpcm0 at intio0 addr 0x00e92000 using dma ch3 intr 0x6a and 0x6b audio0 at okiadpcm0: half duplex
[okiadpcm] とりあえずすべての hw_if メンバ関数に printf を 入れて /dev/audio をオープンしてみる。 set_params が呼ばれてたので、中身を書いてみる。 とりあえず最低限のは書けたけどある意味メインの ソフトウェア処理関数(sw_code)はタイムアウトしたのでまた後日。 つーか 8kHz のサンプリングが渡されてもなあ。 7.8kHz に削れってのかい。
マシン2台あると便利ねえ。 NetBSD でカーネル作ったりリブートしてる間に 隣の Human68k で ami のアドレス帳を書くという3連休だった(笑)。
それとドキュメントがあるってすばらしいねー。 audio(4), audio(9) を読むと割と分かる。 まあそれでも sys/dev/audio* とか sys/sys/audioio.h とかも 片っ端から読んでるんだけどね。
[SxSI] そういえば、こないだ電車の中で SPC のソース読んでた時に 思ったんだけど SPC って (SPCも?) アービトレーションしないのかな。 なんかそれっぽい記述が見つからなかったんだけど。 誰かドキュメント書いてー。
[okiadpcm] mulaw とかいうキーワードあたりのお勉強をはじめる。
[X-Window] うちの X68030 は MMU 載せ替え済みのものを中古で 頂いたものだ。なので FC2 ピンがどうなっているかは 知る由もなかった。が、まさかオープンになっているとも思ってなかった。 今日何気なく mmap が使えるかどうかのテストプログラムを 走らせてみたところ、動いた。
あれ...こいつ FC2 ピンまで切ってあったのか...。
そういうことは早く言ってくれよ...。 ということで X-Window がめでたく使えるらしい。 でも夜遅いので明日インストールしよう。
[X-Window] 朝から早速 X のインストールを開始する。 ソースからコンパイルしてたらまた1週間くらい かかりそうなので、BSD magazine 付録の CD-ROM から 1.4.2 用の X のバイナリを展開する。 あっさり動いた。ちゃんちゃん。
とりあえず kterm と kinput2 を入れて日本語生活を目指す。 が、FreeWnn の jserver がエラー出して起動してくれない。 日本語生活までの道のりは長い...。
[okiadpcm] その傍らで、カーネル内で使うための mulaw → ADPCM 変換ルーチンを sys/arch/x68k/dev/bsd_audio.c から抜き出して Human68k でコンパイルして動作を確認する。 ちゃんと .au ファイルを変換できた。万歳。 Buddy Holly 最高!(わけわか)
しかし、この変換ルーチンって内部で double 使ってるんだけど、 NetBSD カーネルの中って浮動小数点演算って使えないのかな。 単に make clean からやり直せばできるのかな。 だって make clean; make dependall したら5時間以上かかるんだもん。 しくしく。
さあて、この double 問題、どうすべ。
ちなみに FreeBSD の少なくとも3系カーネルだと カーネル内で浮動小数点演算をしても大丈夫だそうです。 うちの研究室の先輩が本業でやってました。
[Human68k/SLIP] 例によって NetBSD/x68k 日記が Human68k のことも 書きはじめてる今日この頃だけど、Human68k 用 TCP/IP ドライバ xip の作者、白方さんに SLIP ドライバを書きたいんだけどという メールを書いてみた。 すぐに返事が返ってきて、ppp.sys のソースを添付してくれていた。 うーむ、ありがたい。 しかし、途方もないことに手を出しているような気がする今日この頃。
[X-Window] 何故か 3つ目の kterm が立ち上がらない。 しかも噂通りかなり遅い。使えねえ。
[jvim] altconsole カーネルで jvim の動作がおかしい (2001/01/27 の日記参照)。 altconsole を抜いたカーネルでもやっぱりおかしくて、 ソースコードを1バイトたりとも元に戻して作った カーネルでもやっぱり動作がおかしいままだった。 なぜ、1月14日に作ったカーネルだと動くんだろう。 この1カ月間すごーく悩んでたのに、原因は それ以降に作ったカーネルはけちって options COMPAT_43 を なくしていたことだった。 つまり jvim3 の動作には COMPAT_43 が必要だと...。 まあ、altconsole が原因じゃなくてよかった。
[okiadpcm] ADPCM 変換ルーチンの double 部分をよーく眺めてみると なんか簡単に整数演算に変換できそうな気がしてきた。 つーか 1000 倍するだけでいけるんちゃう。 ちょっと書いてみよう。...。できた(笑)。 しかも誤差なし。浮動小数点演算に比べて変換時間が3分の1になった。 でも X68000 PRO-II + Xellent30/24MHz の Human68k で 30秒の .au を変換するのに 40秒かかってるんだけど、 まあ気にせず早速 okiadpcm.c に組み込んでコンパイルしてみる。 でもこれってリアルタイム再生できなさげってことかなあ(笑)。
けど、一緒にコンパイルした altconsole のフラグを 間違えてて COMPAT_43 もつけ忘れてたので、 なんのためにカーネル再コンパイルしたのか意味不明。 もう一度改めてちゃんとカーネル作り直す。 寝るまでにタイムアウトしたので続きはまた後日。
[Human68k/SLIP] カーネルコンパイルしてる傍らで Human68k で SLIP ドライバを書いてみる。 なんとなく分かった気になって ppp.s をほぼそのままコピる。 これもタイムアウトしたので続きはまた後日。 でも libether.c と libether.man に書いてある関数を 何気なく ppp.s の真似して書けばいいだけかなあ、と 安易に考える。
[okiadpcm] AUDIO_ENCODING_ULAW 用のソフトウェア処理関数、 mulaw → ADPCM 変換ルーチンは 書けたので、早速ユーザランドアプリケーション から write システムコールを発行してみる。
即パニックした。カーネル開発って面白ーい(笑)。
[okiadpcm] 昨日のは割り込みハンドラを書いてなかったからパニックしたのかな。 とりあえず空の割り込みハンドラを用意してみたけど、 それだけでタイムアウトしたので試してみるのはまた明日。 あ、okiadpcm_attach あたりで割り込みハンドラの登録もせにゃならんのね。
それにしてもいまいち再生方法が分からない。 いや online manual の英語が読めないだけなんだけど。 MI audio layer の write 関数(?)から start_output() 関数に 適当に区切ったデータが渡されるので、それをセットするまでが start_output() の仕事で、実際の再生は intr() に任せるらしい。 てことは、start_output では何をすればいいんだろ。 DMAC の MAR を設定すればいいだけかなあ。 で、渡されるデータの生存期間は?。 うーむ...。
[Human68k/SLIP] 今日はなんとなく SLIP を書いてみる。 相変わらず訳わからん。 ppp.sys はどうやら実際の送信を外部に頼っている気配。 つーか ppp.x だろうけど。 送信処理ってデバイスドライバ内部でやっていいのよねえ。 でもデバイスドライバから IOCS コールは無理なのかなあ。 全く分かってない私。
[Human68k/SLIP] 送信は xip.x から SendPacket コールに送られてきたのを 頭のイーサネットヘッダを切って投げればいいみたい。 これってユーザプロセスの仕事なのかなあ。 その辺の連係、難しいよう。 受信はどうするんだろう。どこでどうやってパケットの 受渡しやってんだかさっぱり見えない。
[okiadpcm] okiadpcm ドライバがパニックする問題は、 うちが書いたテストプログラムがへぼかったのねー。 audioplay(1) を使うとパニックしなかった。再生もされないけど。 DMA 転送開始してみたら、ぴーーーんっていう10数kHzくらいの音が出た。 しかもボリューム切っても鳴り続けてた。恐いよう。 夜中はテストできんなあ。
[mnews] 開発じゃないけど、 ちょっとニュースグループでも読んでみようと思ったんだけど どうして NetBSD の pkgsrc って mnews すら入ってないんだろう。 単にそれを pkgsrc にするユーザがいないだけかな。 と思いつつ、FreeBSD のミラーサイトの distfiles から tarball をとってきて手動でコンパイルする。
しかし mnews のソースって破綻してるねえ。ご愁傷様...。 このスパゲッティソースをメンテできる人ってほんとに天才だろうね。
コンパイルしてみたはいいが、どうもポインタの次元を間違ってるくさい バグがあって動かない。何故じゃー...。
[mnews] 案の定、FreeBSD の ports/japanese/mnews/patches/patch-aa を あてたら直った。どーゆー精度でリリースしとるんじゃ。