SDカードインタフェースでファイルのseekおよび複数ファイルのオープンをサポートしたので、bookwormさんの漢字ROM&表示ルーチンをSDカード上に移植してみました。 フォントイメージはbookwormさんと同じ「美咲フォント」を利用させていただきました。
SDカードには漢字フォントが入ったファイルと表示させたいファイルを用意しておきます。
漢字1文字を表示するごとに漢字フォントファイルのseek&readを行っているので、スピードはいまいちですが、任意のファイルを表示することができます。
こんな感じ。Screen 4だと結構にじみますね。 でも、容量無制限なので、大きなフォントや、複数のフォントの使い分けなども可能です。
こうなるとWeb browserを実装してみたくなりますね。 既にTCP/IPは移植した(SLIPだけど)し...。
もりやんさんのご協力で、8049のROMは何とかなりました。 ありがとうございます!
で、プログラムはもともと2kBしかないですし、それほど大きいものではないので、のんびり眺め始めています。 ただ、命令は1バイトまたは2バイトなので、コード密度はZ80より高いです。
けっこう原始的なプロセッサで、プログラムカウンタの変更が3つに分かれている(最上位ビット、中間3ビット、下位8ビット)など、扱いにくい点も多いプロセッサです。 そのため、たとえば割り込みの扱いがなかなかトリッキーなコードになっています。
割り込みを起こすバス信号で意味のあるのは、以下のもののみです。 コロンの前が入力信号、後が処理ルーチンのアドレスです。
データメモリ(0x20～0x7f)の利用状況はまだ把握し切れていません。 初期化時には以下が行われます。
アドレッシングモードが豊富ではないので、上記のようなトリッキーなところだけ気をつければ、読むこと自体はそれほど大変ではないみたいです。 書くのは大変でしょうけど。
以前話題にした、RS-232Cポートを使って何か入出力できないもんかといろいろ試しています。
今のところわかったのは、RS-232C用のポートは単純な入出力ポートではない、ということです。
実験は、PS/2キーボードをつないでデータを入力する、ということをしてみました。
I/Oポートが固定(0x80および0x81)で割り当てられていて、データバスが出ているところまではいいのですが、問題は割り込み関係です。
PS/2キーボードからの入力があったら、割り込みをかけてキーバッファに入力をさせる独自ルーチンへ飛ぶようにしたのですが、これがうまく動作しません。 というのも、割り込みラインであるRxRDYはINTではなく8049に接続されているようなのです。
そのため、8049の動作がわからないことには全体の動作が把握できません。
また、本体のBIOSからもイニシャライズ時に入出力を行うため、これらを無視するようにする必要もあります。
8049のROMを読み出すことも不可能ではないのですが、手持ちの部品の関係ですぐには無理そうです。 だいいち、かなり面倒ですし。
なかなか思うようには行かないものですね...。
普段はLogitechのMX900とV270という、Bluetoothのオプティカルマウスを愛用している私ですが、どちらも既にカタログからは消えているようです。
それとは別に、飛行機の中など、電波を出せない状況で使うためにコンパクトなコードマウスも時々使います。 サンワサプライの昔のオプティカルマウスを10年以上も使っていたのですが、だんだん使えない場合が多いなど、へたってきたようです。
そこで、近所のPC Worldで買ってきました。 本当はLogitechのレーザーコードレス系のマウスも欲しかったのですが、Bluetoothのマウスは扱っていないそうです。 とりあえずコードマウスのみ。 お値段は16.99ポンド。 ケーブルが本体に収納できるので、持ち運びには便利そうです。
新旧並んで。
レーザーマウスははじめて使いますが、なんかセンシングがふらつくような?
AVRで音声を出すことができたので、今度は映像信号に挑戦中です。
映像信号の詳細についてはこのへんに詳細な説明があるので、いろいろ調べながらトライしてますが、まだきちんと理解しているわけではありません。
基本的には、PWMを使って正確なタイミングで同期信号を出して、それに映像信号を載せればいいみたいです。 手元のジャンクには、PAL信号用のチップもある(イギリスはPALですしね)のですが、ここは勉強のためにも、まずは同期信号だけでもうまく出せればと思っています。
基本的には、水平ラインあたり63.555us(モノクロなら63.492us)を単位とし、水平ブランキング期間の10.9us中、4.7usの期間はLレベルにすればいいみたいです。 ただ、コンポジット信号にしたときのインタレース方法や等価パルス、映像信号の重畳方法などは良くわかっていません。 あちこち調べてると、重畳はワイヤードORのようですが。
ノンインタレース信号やRGB分離のほうがアルゴリズム的には簡単なのかも。
ちなみに、AVRで簡単におおよそのタイミングで同期信号を作って試してみていますが、いまのところうまく同期が取れているわけではありません。 ただ、ちらつくにせよ画面に何か出るので、思ったより映像信号の作成そのものは手の届かないほど遠いものではないということだけはわかりました。
ただ、電圧レベルが-40IRE(0V)から100IRE(1V)のアナログ信号なので、ちゃんと同期信号と映像信号で電圧をあわせてあげないといけないのかも。 特に、同期信号だけ出したら0V～3.3Vまでフルスイングしてしまうので、その辺の調整は必要でしょう。
いずれ、ちゃんと映像出力をして音声と両方あわせてみたいですね。 でも、AVRの処理能力ではカラーは難しいかもしれません。 色差信号を計算することを考えると、周波数さえ満たせれば、純粋にデジタルRGBが楽なのかしらん。といってもデジタルRGBのモニタなんて持ってないので、アナログRGBになるかな。こちらで一般的なSCARTはどうなっているんだろう?
ATtiny2313でのステレオサウンド再生テストです。
FT245RLモジュールと、ATtiny2313を使い、きわめて簡単な回路でやってみました。 データは単に垂れ流しているだけです。 これで少しだけBitBangモードの使い方がわかったような気がします。 回路はこんな感じ。 端子はすべてFT245RLのものです。
ポートが8ビットなので、LSBの1ビットをLRチャネルの選択に使い、実質7ビットですが、サンプリング周波数は結構高いので、それなりに聞こえます。 ただ、結構プチプチとDCっぽいノイズが乗りますね。 LPFのカットオフはデューティ比50%の時に約16kHzなのですが。
AVRを20MHzで使っているので、PWMの周波数は次のようになります。
20,000,000 / 256 = 78,125 (Hz)
そこで、ffmpegを使い、次のようにして8ビットステレオファイルを作ります。
ffmpeg -i ソースファイル -f rawvideo -acodec pcm_u8 -vn -ar 39062 出力ファイル
この出力ファイルを次のようなソースで吐き出せばokです。
#include <windows>
#include <stdio.h>
#include <sys/unistd.h>
#include "ftd2xx.h"
int main(int argc, char **argv) {
FT_HANDLE ftHandle;
FT_STATUS ftStatus;
DWORD written;
unsigned int count = 0, i;
unsigned char val[4096];
FILE *in;
if (argc < 2) {
fprintf(stderr, "Usage: %s \n", argv[0]);
return 1;
}
if (!(in = fopen(argv[1], "rb"))) {
fprintf(stderr, "Error: opening input: %s\n", argv[1]);
return 1;
}
ftStatus = FT_Open(0, &ftHandle);
if (ftStatus != FT_OK) {
fprintf(stderr, "Error: opening USB device\n");
return 1;
}
ftStatus = FT_SetBitMode(ftHandle, 0xff, 1);
if (ftStatus != FT_OK) {
fprintf(stderr, "Error: initializing USB device\n");
return 1;
}
ftStatus = FT_SetUSBParameters(ftHandle, 4096, 0);
if (ftStatus != FT_OK) {
fprintf(stderr, "Error: setting USB buffer size\n");
return 1;
}
ftStatus = FT_SetBaudRate(ftHandle, 78125 / 2 / 2);
if (ftStatus != FT_OK) {
fprintf(stderr, "Erro: setting baud rate\n");
return 1;
}
while (1) {
if (!fread(val, 4096, 1, in)) {
break;
}
for (i = 0; i < 4096; i++) {
if (i % 2) {
val[i] |= 1; // right
} else {
val[i] &= 0xfe; // left
}
}
FT_Write(ftHandle, val, 4096, &written);
if (written == 0) {
break;
}
}
FT_Close(ftHandle);
fclose(in);
return 0;
}
AVR側はきわめて簡単で、次のようなソースになります。
#include <avr/io.h>
#include <avr/interrupt.h>
ISR(TIMER0_OVF_vect) {
unsigned char val = (PINB & 0xfb) | (PIND & 0x04);
unsigned char channel = val & 0x01;
val &= 0x0fe;
if (channel) {
OCR0A = val; // right
} else {
OCR0B = val; // left
}
}
int main() {
PORTB = 0xff;
PORTD = _BV(PD2);
DDRB = _BV(PB2);
DDRD = _BV(PD5);
TCCR0A = 0b10100011; // OSCA enable, OSCB enable, fast PWM
TCCR0B = 0b00000001; // OSC=fCPU
TIMSK = _BV(TOIE0);
sei();
while (1);
return 0;
}
FT245RLのボーレートの設定が、サンプリング周波数の半分(78125/4)なのが謎。 これをサンプリング周波数と同じに設定してしまうと、再生が倍速になってしまいます。
CPLDも書けるようになったので、そちらはブレッドボードからユニバーサル基板へ実装を移したあといったん終了。
んで、秋月のFT245RLモジュールをテストしました。 とりあえず何をしたってわけでもないですが、秋月のサンプルプログラムを動かしてみました。
自分でUSBデバイスをいじれるってのはなかなか良さそうですね。 BitBangモードはターゲットとどうやって同期を取っているかなど、まだ良くわかってないことがあるので、その辺はこれから勉強です。
ATtiny2313でテストするときも、今まではPC-6001からデータを入れていましたが、USBを使えると一段手間が減って便利そうです。 ていうか、実験でPC-6001は既に電源とデータ入出力器としての役割しか果たしてなかったりします...。 結構便利なんですけどね。
今日はひどい目にあいました。
買い物から帰ってきて、駐車場から大荷物を抱えてエレベータに乗りました(うちのフラットの駐車場は地下にあります)。
すると、ほんの数秒もしないうちに、「ブツッ」と音がしてエレベータが止まってしまいました。 同時に電気も消えて、真っ暗です。
一瞬で「閉じ込められた」ことがわかったのですが、まぁ呼び出しボタンを押せばいいのだろうと、別にあわてもせず呼び出しボタンを押しました。 ところが、自動音声が鳴るだけで、誰も応答してくれません。
いろいろボタンを押しまくっていると、サイレンが出るボタンがあったので、それを押しまくりました。 しばらくすると気づいてくれる人がいて、リフト会社に連絡してくれました。
しかし、リフト会社のエンジニアが来るまでは3時間もかかり、その間、ずっと暗い中に閉じ込められていたのでした。
ドアを開けてもらうと、なんと地下の乗った位置からほんの1メートルくらいしか上がってませんでした。 原因は不明ですが、ブレーカが落ちたような症状で、エンジニアがコントロールルームでちょいといじればすぐに復旧するレベルのもののようでした。
しかし、閉じ込められている側からはそんなことはわかりませんので、暗い中うずくまっているしかありませんでした。
同じフラットに住んでいた日本人のご夫婦が、ずっと外で様子を教えてくれたのは有難かったです。 ちょうど今日でmove outして、日本に帰任なさるそうです。 ありがとうございました。お気をつけて。
パラレルポートからXilinxのCPLDに書き込めるようにJTAG用の回路を作ったのですが、これがうまく動いてくれません。
回路は次のようになっています。
WebPack 9.2iのiMPACTから通信させようとすると、デバイスIDがオール0またはオール1になってしまいます。 明らかに通信不良です。
AVRのISPケーブルの場合は何の問題もなく一発で動いていたので、なんともわかりません。 単にレベル変換をしながらD0～D2をTDI, TCK, TMDに接続し、TDOをSLCT入力に接続しているだけなんですけどね。
ちなみに今回は3.3Vへの変換にSHARPのPQ3RD23を使いました。 安かったので。
(21 Mar. 2009 7:05pm更新)
理由がわかりました。D-sub25ピンのGNDとJTAGのGNDを接続し忘れていたのでした。 なんともみっともない理由です。 お恥ずかしい...。
ATtiny2313の実験回路を作ったので、ちょいと回路を変更してPWM出力をしてみました。
変更はきわめて簡単で、実験回路のPB2/OC0A(14番ピン)をD2から外し、RCAコネクタの信号線(内側)に入れます。 RCAコネクタのもう片方はGNDに接続します。
本体からの入力が1ビット使えなくなってデータが不正確になりますが、この際気にしないことにしましょう。
音質を気にするならローパスフィルタを設けるべきですが、とりあえずこれだけでも音は出ます。 ただ、出力電圧が高いので本当は抵抗を入れたほうがいいでしょうね。
とりあえず8bitカウンタを使ったPWMなのですが、この場合は以下のいずれかになるようです。
周波数とデューティ比の両方を可変にするには、16bitカウンタを使う必要があるようです。
なお、デューティ比50:50の出力は、まるでPSGそのものです。 ファミコンのあの独特の音も出せそうですね。
プログラムはこんな感じです(AVR Studioのアセンブラ使用)。
.include "tn2313def.inc" .def regB = r16 .def regD = r17 .def Temp = r18 .org 0 rjmp RESET rjmp 0 in regB, PINB ; input from PC (bit4, 3, 1, 0) in regD, PIND ; input from PC (bit7, 6, 5) andi regB, 0x1f andi regD, 0x70 lsl regD or regB, regD ; regB = input out OCR0A, regB reti RESET: ;; port setup ldi Temp, 0x1b ; 00011011 out PORTB, Temp ldi Temp, 0x74 ; 01110100 out PORTD, Temp ldi Temp, (1 << PB2) out DDRB, Temp ldi Temp, 0x00 out DDRD, Temp ;; PWM setup (change here to make duty or frequency controllable) ldi Temp, 0b01000011 ; OC1A enable, 8bit PWM out TCCR0A, Temp ldi Temp, 0b00001100 ; I/O clk/256, OCR0A=frequency control out TCCR0B, Temp ;; interrupt setup ldi Temp, (1 << ISC11) out MCUCR, Temp ldi Temp, (1 << INT1) out GIMSK, Temp sei LOOP: rjmp LOOP
ご参考まで。
私の手元にはATmega88は一個しかなく、やたら使い回ししまくって壊すのも怖いので、先日買ってきたATtiny2313で実験を始めました。
まず、ラッチを使わずにデータをハンドルできるかどうかです。 次のような試験回路を使いました。
使っているORゲートはHC32です。 この回路では3段入れているので、遅延は50nsに近くなります。 この数値は20MHzの1クロック分にもなるため、結構無視できません。 AHCなどの高速品も考慮に入れるべきでしょうね。
とりあえずPC-6001の15.7944MHzをクロックにして試した結果は次のようになりました。
以上のことから、とりあえずAVRから見て入力側はラッチがなくてもいけそうです。 出力側はちょっと厳しそうですね。
今回はロジアナでの計測まではしていません。
いずれやるつもりです。
次に、WAIT信号(拡張スロットの7番ピン)についても調べました。 実はPC-6001のWAIT入力はちゃんと機能します。 実行時間がわかるほどのWAITを入れると、画面が乱れます。 これは、CPUが止まることによってVDG(MC6847)からのDMAも止まるためでしょう。
ただし、あまりに長時間止めると、本体がハングアップします。 これはおそらく、WAIT中はメモリリフレッシュを行わないため、DRAMの内容が消えてしまうのが原因だと思います。 まぁ、AVR内部のタイマ割り込みと組み合わせて使えば問題はないでしょう。
いずれにしても、ブートアップ時にきわめて有効に使える手段です。
と、言いたいのですが...。
ちょっとだけ追試したところ、どうもPC-6001mkIIでは有効に機能していないようです。 初代では回路上でもWAIT入力はちゃんとバッファリングするなど正式な入力端子としての扱いをしているのですが...。
ムービーの同時再生ですが、Audio/Videoのバイト配置を工夫することで、256x192ドット、12288Hzで12fps程度は出るようになりました。 なにせ、ファイルサイズに実質制限がないので、とても楽です。 ちなみに、現在ムービーで扱っているファイルのサイズは10MBのオーダーです。 性能はがんばればもう少しいけそうです。 まぁ、そのうち気が向いたら別のムービーでも録画してみます。
面白いことに、ニコニコ動画に出した20kHzよりも12kHz程度のほうが音質は良いみたいなんですね。 とはいっても所詮noisyではありますが。 DMAのタイミングとの関係が何かあるのかもしれません。
次のステップは、PC起動時にSDカードから起動ファイルを読み込んで自動立ち上げしたいということです。
SDOSを起動して、そのあと任意のファイルを起動してもいいですし、ベルーガのような大きなソフトが自動的に起動するというのもありです。
SDカードの転送レートは十分あるので、0x4000～0xbfffの32kBにSRAMを配置すればいいといえばいいのですが、理想的にはもっと大きなメモリを実装して、バンク切り替え可能にしたいです。 すると、ContikiなどのOSで、複数のプロセスを切り替えて使ったりできて便利です。
MSX-DOSのようにプログラムの格納番地を固定化してバンク切り替え数分のプロセスをサポートするという手もありますし、それこそelfフォーマットをAVRで解析させてリロケータブルにするというのもありでしょう。
また、起動時にPC本体とは無関係に(拡張)メモリにアクセスする必要がある関係上、アドレスとデータにバッファが必要になるのですが、逆にこれをうまく使えば画面書き換えをPC本体ではなくAVRに行わせることもできるでしょう。 そうすると、またいろいろと可能性が出てきそうです。
とまぁ、いろいろと可能性があって面白いんですが。
当面厄介なのは、またしても回路の実装なんですよね。 なんせアドレス線は本数がありますから...。
いい加減プリント基板を作る訓練をしなければいけないかな?
一応同時再生ができるようになったので、例によりニコニコ動画からムービーを適当に拾ってきて録画してみました。
TVで見ると色が付くのですが、キャプチャで録画したので本来の白黒になってしまっています。
動作環境は以下のようになっています。
以上から、音声は20480Hz/4ビットとなるのですが、DMAの関係で、やはり今のところ音質はどうにもなりません。 画面出力を切ると、10kHz程度でもかなりの音質になるのですが。
上記の条件から、転送レートは以下のようになります。
(6144(video) + 2048(audio)) * 10(fps) = 81920 = 80kB/s
やはり拡張スロットからAVRを介して直接入力しているだけのことはあり、かなりの転送レートが出ます。 しかも、バッファを持たない完全ストリーミングなので、PC側のメモリをほとんど消費しません。 プレイヤーのプログラムも、0.5kB程度の容量で実現できています。
以下が、プレイヤーの中心部です。
_play_loop: ld hl, #0xe200 ;11 (hl=VRAM position) ld d, #16 ;8 -> 19 (d=counter) _read: ld a, #AVRSD_READ ;8 out (#0x00), a ;13 nop ;5 -> 26 _read_command_loop: in a, (#0x00) ;13 cp e ;5 (e=BUSY) jp z, _read_command_loop ;11 -> 29/loop or a ;5 jr nz, _terminate ;8/13 in a, (#0x00) ;13 (size L) in a, (#0x00) ;13 (size H) ld b, #0x80 ;8 -> 47 (b=loop counter=dec x 384) _render_loop: in a, (#0x00) ;13 out (#0xa1), a ;13 (audio output) ini ;19 ini ;19 ini ;19 jp nz, _render_loop;11 -> 94*128=12032 dec d ;5 jp nz, _read ;11 jp _play_loop ;11 _terminate:
ご覧のとおり、ほとんどinしているだけです。
このセッティングだと、画像:音声=3:1固定のため、fpsを上げると同時に音声周波数も上がってしまいます。 しかし、512バイトセクタ単位で読み込んでいる関係で、他の比率はなかなか難しいものがあります。
それにしても、DMA ON時の音質は何とかならないものでしょうかね...。
私の手元には、一部欠けていて、かつ非常に不鮮明ではありますが、PC-6001の回路図があります。 以前はI/O誌の解析記事もあったはずなのですが、残念ながら一部を残して捨ててしまったようです。 手持ちの資料をよく調べてみたところ、いくつか新事実(?)がわかりました。
一つ目はSRAM付きSDカードインタフェースを作るときにとても役立ちそうです。 初期ロードの際にCPUを止められます。
2つ目は既にAVRのクロックに活用していますが、PC-6001mkIIでは削除されてしまっているようです。 残念。
3つ目は本体をばらさないといけないですが、見たところピン自体は普通に立っているので、本体自身に手を入れることなく信号を取り出すことができます。
わかっている範囲では、TPは次のとおりです。
当たり前かもしれませんが、この情報は無保証です。あしからず。
手持ちのPC-6001mkIIでも試してみました。
なんと、cloadでデータがロードできません! 初代とは何か違うのでしょうか? それとも、故障しているのでしょうか。
これでは、実験用のプログラムが読み込めないため、ROMレスシステムが完成するまで実験ができません...。
それと、初代では拡張スロットの16ピンに、本体のクリスタル発振がそのまま出力されていたのですが、それもなくなっているようです。 初代だと、それをAVRの外部クロック入力として使うことができます。 15.9744MHzなので、かなり使えるのですが...。
なんかいろいろ面倒ですね。
今日は9時ごろ起き出して、しばらく実験などをしたあと、どうしても眠くなって昼ごろまた寝てしまいました。
気づいたら午後6時! 昨夜そこそこ寝られたのに、今日一日寝て過ごしてしまいました。 おかげで、用事がなにもこなせませんでした...。
時差ぼけが残っているような感じはあまりしないのですが。
なんでしょう?
現在、AVRは内蔵の8MHzクロックで動作させています。 もともと手持ちのものが古い(2世代目)ATmega8Lで、2.7V～5.5Vでの駆動が可能な代わりに8MHzまでの動作となっているためです。 姉妹品のATmega8は最高16MHzですが、4.5V～5.5Vでないと動作しません。 3.3V動作のSDカードまでバッファを介したくなかったため、これはこれで悪くないチョイスではありました。
しかし、現行のAVRは3世代目に入っており、mega8系の後継にはATmega88(他に48/168/328)があります。 これは、2.7V～5.5Vで20MHz動作が可能となっています。 さらに低電圧(1.8V～)対応版として、ATmega88Vがあります。 型名の最後にVがつくものはみなこのバージョンで、こちらは10MHzまでの動作です。
電力消費を減らしたP/PVバージョンもあるのですが、そこまでは拘らないので別にいいです。
いずれにしても、ATmega88が後継としてはいいチョイスということです。 幸い、以前日本に行ったときにためしに一つ買っておきました。
ただ、8MHz以上の周波数で動作させる場合は、必ず外部にクリスタルが必要です。
というわけで、今月頭に日本に行ったときに20MHzのクリスタルとコンデンサを少々買っておきました。
現在のSDカードドライバは、データの連続読み込み部分をかなりチューンしてありますが、1バイト読み込むためにはPC本体側で29クロック必要です。 そのため、inir(24クロック)は使えません。
また、セクタをまたぐアクセスにはそこそこ時間がかかります。 とは言っても、
という感じでZ80とは根本的に異なるので、体感するようなことはほとんどないのですが。
でも、やはりZ80側をフルパワーで動作させても追従させてあげたいので、88に差し替えてみようかと思っています。 幸いI/Oも結構空いていることですし。
でも、ATmega8L、5個も買っちゃったんだよなぁ...。
ショックから気を取り直して、画像および音声の同時再生を試みました。
結果は...できたといえばできました。 現在、画像は128x96x24fps, 音声は約12kHz/4bitとなっています。
ただ、同時再生の場合、VDGからのDMAを止めるわけには行きません。 これまでに調べた限りでは、VDGのBUSREQなどのタイミングをソフトウェアから取ることは不可能そうです。 そのため、音質はかなり悪いです。
割り込みは止めていますが、それでも正確なタイミングが取れないため、きついものがあります。 以前の測定で、水平帰線ではBUSACK有効(L)期間が41.2us、無効(H)期間が22.7usでした。また、垂直帰線中の無効期間は4482usでした。 ここから計算すると、CPUの動作率は以下のようになります。
(22.7 * 192 + 4482) / ((22.7 + 41.2) * 192 + 4482) =~ 52.8 %
また、水平帰線中、動作が止まる時間は次のようになります。
41.2 / 1000000 * 3993600 =~ 164.5 clk
つまり、動作中にコントロール不能で164.5クロックも停止してしまうわけです。 これは厳しいですね。
これじゃ恥ずかしくて動画共有サイトには出せないかなぁ?
何かいい方法はないものかなぁ。
今日、AVIファイルの解析プログラムを書いていて気づいたのですが、ffmpegにはモノラル1ビットのビットマップにするオプションがあるではないですか!
ffmpeg -i <file> -f rawvideo -pix_fmt monob ...
さっそくそのオプションで変換し、画像部分を取り出して、圧縮も何もせず力技の再生プログラムを書いて試してみると...。
何のことはない、簡単に再生できてしまいました。 しかも色(グレイスケール)が誤差拡散されている! 以前PC-8001で見たものと同じです。あれ、どうやったんだろ、すごいなぁと思っていました(あ、もちろんPC-8001版でこれを使ったのかどうかはわかりませんし、それに関係なくすごいですよ)。
なぜこれに気づかなかったんだろう。
私は、自分でビットマップからモノクロへの変換アルゴリズムまで書いてムービーファイルを作っていたのでした...。
しかも、誤差拡散なんて面倒なのでやらないで。
まさにReinvent the wheelの極致!
ああ、私ってお馬鹿さん...。
まぁ、以前の画像データの特性(RLEがかけやすい)と作成した圧縮により、自前のアルゴリズムのほうがfps値が上がっているので、良しとしましょうか...ヒクヒク。
ちなみに、さらに間抜けなことに、最初は以下のようにしていたため、できたファイル(RIFFフォーマット)からさらに自前のプログラムで加工していました。
ffmpeg -i <file> -vcodec rawvideo -pix_fmt monob ... xxx.avi
まぁこれは、もともと画像と音を同時再生するためにやっているのではあるんですが。
アホな自分へのショックが大きすぎて、立ち直りに時間がかかりそうです...。
AVR-SDカードインタフェースは調子よく動いているので、ストリーミングを試してみました。
まず転送速度ですが、SDカードからの読み込み速度は現状でおよそ30kB/s出ています。 1秒でPC-6001のフリーエリアがいっぱいになってしまいますね(苦笑)。
ムービー音声これまで、256x192ドットでの動画はオンメモリで8fpsでも厳しかったのですが、アルゴリズムを見直したところ、8fpsなら特に問題なく動作するようになりました。 in命令のみでデータが読み込め、メモリアクセスが不要なのが効いています。 ちなみに、inirを連続させて生データを読み込む方法だと、理論値でもかなり厳しいのと、現在はinirのスピードにAVRが追いつきません(AVRのクロックを上げればいいだけですが)。 したがって、圧縮アルゴリズムは以前のものをそのまま使っています。
動きの激しい部分などは少々スキャンラインが見えてしまいますが、何とかがんばっている、という感じです。
余談実はムービーより音声のほうが厄介です。 タイミングを厳密に取る必要があるためです。
- サンプリング周波数は8000Hzおよび11025Hz
- DMA OFF
- 割り込み禁止
- 1チャネルのみ使用(4ビット、実のところは2ビット程度)
上記の条件だと、そこそこクリアに聞こえますが、1セクタごとにリードコマンドを発行する関係上、ポツポツとノイズが乗ります。 リードする際の待ち時間がSDカード依存で、平準化できないためです。
ここで以前の3チャネル高品質再生ではなくて1チャネルにしているのは、ムービーとの同時再生を目論んでいるためです。
当然、同時再生をするためにはDMAをONにしなければなりません。 再生時は多少時間的余裕があるので、待ち時間を減らしてDMAをONにしてみました。
すると...かなりnoisyです。 スピードの問題というよりは、BUSACKの最中に処理ができず、再生速度にムラができてしまうためかと思います。
ところで、PSGの音量は以前解説したように設定値に対して対数の関係にあるのですが、それを勘案して音量レジスタの値をエンコードしてやると、何も考えずにリニアに設定するときよりも音質が悪化します。 不思議ですが、もともと4ビットと、解像度が悪いためかもしれません。
いわゆる東芝型の50pin IDEを備えた1.8インチIDE SSDですが、最近少しづつ商品が出てくるようになりました。
秋葉原ではSamsungのMCCOE64G8MPR-03A(64GB)が発売されているようです。 初物でSLCタイプということもあり、価格は少々高く、90,000円内外します。
また、PhotofastからはG-Monster 1.8IDEの東芝インタフェース版が発表されていて、まもなく発売されるようです (Siroさん情報ありがとうございます)。 日本でも扱っています。 容量は32GBおよび64GBで、価格はオープンプライスとなっています。 詳細はわかりませんが、
どうでもいいのですが、台湾のPhotofastのページ、英語版や中国版でもflashには日本語が含まれています。
各国語版を作る手間を省くためなのかもしれませんが、それだけSSD関連の日本人からの注目が熱いということなのでしょうね。
