コメント
Unknown
(
うだがわ
)
2009-03-29 17:08:08
このページに触発されてつい、出来心です。
ttp://www7.big.or.jp/~kerokero/avr/rsmoni(m168-20M).lzh
自分も今日試しました。
32*16が精一杯でした。
Unknown
(
nekosan
)
2009-03-30 00:19:58
うだがわさん、こんにちは。
３２×１６まで行きましたか！って、テキストＶＲＡＭだけで内蔵メモリ一杯一杯じゃないですか！
とうことは、表示用のＶＲＡＭ（ドットイメージ）はレジスタだけで済ませているんでしょうかね？
いや、あれかな？１文字１文字個別にデコード…？
うーん、お見事です！ＭＥＧＡ８８／１６８ではまさに限界一杯一杯ですね。すごい。
Unknown
(
うだがわ
)
2009-03-30 20:56:22
nekosanさんこんにちは。
RAMに展開して表示というのはしていません。
ROMから読んでそのままシフトして表示ですね、
ですからROMへの文字データの焼付けを一工夫しています。
ROMの3400-3FFFがデータです。
↓一応、証拠ビデオです。(26MB)
http://www7.big.or.jp/~kerokero/avr/rsmoni_test.mpg
ROMを焼いて動かすにも手間が掛かると思いまして^^
起動直後はスクリーンセイバーもどきです。
音痴なのは仕様ですので念のため。
ではでは。
Unknown
(
nekosan
)
2009-03-30 23:51:17
ムービー拝見しました！
うーん。しかも１１５２００ｂｐｓですか… 凄い。
制御コード用の特殊処理とか含めると１１５２００ｂｐｓは難しくなかったですか？
ＴＩＮＹ２３１３で以前作ったとき、スクロールをどうしても組み込みたかったんですが、これにだいぶ時間を取られてしまって、通信速度は適度に遅いものを選ばざるを得なかったんですよね…
もしかして、メロディーデータもＵＡＲＴから入力して鳴らしているんでしょうか？ここまで表現力があると、いろいろ応用できそうですねぇ。
＞ROMから読んでそのままシフトして表示ですね、
＞ですからROMへの文字データの焼付けを一工夫しています。
８ドット表示する合間にデコード処理をはさみこんでいる…という感じでしょうか？ハードウェア乗算器を上手く使うとこの合間に入りきるってことでしょうかね… 面白そうだなぁ。後でロジック考えてみよう…。
Unknown
(
うだがわ
)
2009-03-31 07:11:14
nekosanさんおはようございます。
UARTは走査線割込み内でポーリングで読んでリングバッファ(64Byte)に蓄えます。
TEXTへの反映はメインループで処理しますので処理時間は気にしません。
CLSやスクロールも余裕ですね^^
メロディーはVB期間で割込み処理でこなしています。
音痴はDTMFによるもので、Dial3212333222399321233322321
となっています。（古いネタですいません）
ではよろしくです。
Unknown
(
nekosan
)
2009-03-31 19:30:57
一つ勘違いしてました…
ＭＥＧＡ８８、ＭＥＧＡ１６８のｓｒａｍは１ＫＢですね。ｅｅｐｒｏｍの容量見ちゃってました…（^_^;）
６４バイトのリングバッファですか。なるほど。割り込み駆動でメイン側で処理するのであればスクロールも余裕かもしれませんね。
262本×60フィールド×10ビット＝157200bpsまで可能ってことで、115200ｂｐｓなら処理し切れますからね。
VT100互換に使えちゃうかも…
Unknown
(
うだがわ
)
2009-04-01 06:49:54
>ＭＥＧＡ版でも考えるか？秋月でＭＥＧＡ８８が
>２５０円で手に入るご時世だし。
入手性でMega88に移植した方が良いのかな・・・
あ、是非nekosanさんにトライして欲しいかも
表示位置調整付き、VT100互換で是非。
よろよろ。
Unknown
(
nekosan
)
2009-04-01 22:59:22
115200bpsだと、短い文字列＋スクロールが繰り返されるようなシチュエーションでデータの取りこぼししないか、アタマを悩ませそうな気がしてきました。
想定しているのは、玄箱のシリアルコンソールに直接繋いで使うような感じです。
玄箱起動メッセージのうち、1行の文字数が多い場合はなんとか処理しきれると思うんですが、数文字毎にスクロールするような場合が連続するとどの程度まで耐え切れるのか…
もっと過酷なのは、arduinoなどのマイコンに温度センサーとか繋いで、温度を数桁の数字+改行マークとしてモニターする場合、数バイト毎に改行することになるので…
ブロック転送処理の処理時間次第なんですが、このあたりは命令表とのにらめっこですね…。
テキストＶＲＡＭ1枚512バイトと仮定して、それを転送するのに必要な命令数はザックリ4×512≒約2000クロック程度でしょうか？20MhzのAVRでは水平同期2本分近い処理時間ですね。
ポストインクリメント付きのLDとSTで1バイトずつ読み書きしていく処理を想定しています。
Z80のレジスタペア（16ビット幅）のPUSH,POPに相当するような命令も無いですし…。ＳＲＡＭのあるアドレスから別のアドレスに直接転送する命令も無いみたいなので。
スクロールを放棄して、一番下まで行ったら一番上の行に戻るという逃げ方はあるかな… 無いなぁ。
私が作ったスプライト表示器の処理のように1本ずつ間引いて表示すれば、その隙間に処理していくことも可能だろうと思いますが…うーん。
Unknown
(
うだがわ
)
2009-04-02 05:25:28
スクロールは表示の垂直方向オフセットを変更出来るようにすれば
内容のブロック転送は避けることが可能です。
テキストの改行処理は表示座標変更と1行32バイトの消去のみなので10μｓ程度で済みますよ。
Unknown
(
nekosan
)
2009-04-02 20:47:39
なるほど。オフセット値をずらしていくなら確かに処理時間は心配要りませんね。
最初、計算処理１バイト（８ドット）毎にオフセットの計算加味しないといけないとばかり思っていたんですが、よく考えたらせいぜい１ラインの先頭で１回やっておけば十分ですし、もっと言えば８ラインの間はオフセット値を再計算する必要も無いので、この方式なら問題ありませんねぇ。
昔の８ビット時代のＰＣが（当然ながら）ＶＲＡＭアドレスが固定だったので、固定観念になっていたんでしょうね。
処理能力上、最も気になっていたのがこのスクロールと画面クリアだったんですが、その辺りが解決ついて、私が悩んでいた障壁は大分クリアになった感じです。
ちなみにうだがわさんが挑戦した時にネックになったところはどのあたりでしたか？
Unknown
(
うだがわ
)
2009-04-03 08:10:46
苦労したのは、TEXTの横方向の高密度化ですね
最初１文字ごとにCGROMとしてのアドレス計算に時間が掛かっていて、
文字同士の間が空き過ぎて間抜けな表示になったことです。
どうにか最小限のコードでCGアドレスを得るかで、
CGをROMへ焼付ける際にインターリーブにして
アドレス計算を無くすまでが長かったです。
一応、最初のHEXをスクロールでの対応に変更しました。
と同時に8KBのレンジに収めたのでMega88でも動作確認できるかと思います。
（※Mega16とMega88でコード互換かの確認はしていません）
いや～、色々と奥が深いですね。
Nekosanさんの広い知識には関心させられます。
Unknown
(
nekosan
)
2009-04-04 02:34:57
＞苦労したのは、TEXTの横方向の高密度化ですね
このあたりって、ビデオ表示ではなにかとついてまわる課題って感じですよね…。この辺りがやっぱりマイコンとＣＰＬＤ/ＶＨＤＬとの違い…みたいな…。
私がＴＩＮＹ２３１３でテキスト表示やったときは、文字がデカかったので間が空いててもあまり気にしなかったのですが（＾_＾）。というか、そもそも１ラインがデコード（ビットイメージ作成）、次の１ラインが表示だけという手抜きッぷりですが…
ムービーではかなり細かい文字を表示されていたので、あの感じだと文字と文字の間はせいぜい１０クロック以内じゃないかと思うんですが、その程度でテーブルサーチ（？）完了しているっていうのが驚異的だなぁと思います。
Unknown
(
うだがわ
)
2009-04-04 18:57:05
ど～も、作りかけですが、
↓こんなものを作っています。
http://www7.big.or.jp/~kerokero/avr/pactest.mpg
↓ROM
http://www7.big.or.jp/~kerokero/avr/pactest(m168-20M).lzh
忙しくならなければ今月中に完成させたいです。
板違いですいません。
Unknown
(
nekosan
)
2009-04-04 23:36:45
このＢＧＭはもしや「リ○○ラ○○」を作っているとか！？
ってことは無いですね。見た感じ、表示処理部分はほぼ出来上がりって感じですね。迷路もちゃんと綺麗な曲線で組まれていて、いい雰囲気です。
テキスト文字表示と比較して、ドット単位で位置をずらさないとならないスプライト表示って、タイミングかなりきびしくないですか？
私はデコードと表示を両立できなかったので、仕方なく1ライン置きにデコード行と表示行って具合に分けちゃったのですが…
とにかく、完成頑張ってください。応援してます。
あ、そうそう。この間マルツのメールマガジンで
https://www.marutsu.co.jp/user/shohin.php?p=62274
こんなの見つけました。一応入手だけしてまだ使ってませんが、もしかしたら入力デバイスとして結構使えるかも…
4方向としか書いてないのでナナメに入るのか微妙だったり、表面実装なのでかなり小さかったり…と。
でも単価１８９円はなかなかかと。
Unknown
(
うだがわ
)
2009-04-05 18:35:29
ほんの少し進展･･･
リンク先の内容は更新してあります。
リ○○ラ○○の曲。pacは曲でないのでPGから叩かないとならないので、
とりあえず走行テストの為に入れています。
>スプライト表示って、タイミングかなりきびしくないですか？
むちゃ厳しいですよ。横に太るのでもう1ck削りたいのですが、
今のところ限界です。もぅ自分の頭ではどうにもできません。
>とにかく、完成頑張ってください。応援してます。
あ、ありがとうございます。
何とか完成させたいです。 でも懸念材料は一杯ありまして、
・スタックマージン
・ＲＯＭ、ＲＡＭの残量
・処理時間
・バグ(スタック溢れ？)
色々とコンパイラと相談しながらチマチマ進めていますが、
以外とコンパイラさんが機嫌悪く、
こちらの望んだコードを吐いてくれません;_;
>こんなの見つけました。
あ、いいですね、タクトＳＷの寄せ集めは結局指の位置を
目で確認してしまうので、十字は一体型がいいですよね。
操作できるようにしたら試してみます。
あ、バグで壁が壊れて出ていってしまった>monster orz
それではまた。
Unknown
(
nekosan
)
2009-04-05 22:47:58
データ量をそれとなく計算してみたんですが、１ＫＢのＳＲＡＭを登載していても、これを全部ビットイメージでＶＲＡＭ展開したら入りきらないサイズでしょうから、テキスト文字表示の時のように、内部ではコード化しておいて、デコードしながら表示する感じなのかと想像しているんですが、ドット単位の移動ってどんな風に実現しているんでしょうかね？
先日のテキスト文字表示がベースになっているとしたら、あらかじめ１ドットずつずらしたパターンを必要数だけ用意しておいて、そのコードをテキストＶＲＡＭ上に置いていく感じなのかなぁ…と想像していたのですが…
それとも、リアルタイムでスプライトのＸ、Ｙ座標から画像の重ね合わせ処理をやっているんでしょうかね？
＞こちらの望んだコードを吐いてくれません;_;
アセンブラじゃなかったんですね…。あらためてびっくり！
そういえば、以前後閑さんがＰＩＣでＳＰＩの出力端子を使ってビデオ表示してましたね。
http://www.picfun.com/app24Fframe.html
シンクロがPB1（PWM?）、映像がPD7のようなので、映像信号は1ドットずつ書き出しているように見えるのですが、後閑さんのような方法にするとソフトウェア上は少し余裕が持てるかも知れませんね。
…ＳＰＩだと完全にシリアルなので、多段階の濃淡やカラー表示には向かないのですが…
Unknown
(
うだがわ
)
2009-04-06 07:54:54
なるほど、
SPIですか確かに8bitずつハード的な補佐が入ればかなり楽になりますね。
こちらの望んだボーレイトに調整できるのか分かりませんけど、
全く頭に無かったので検討してみたいと思います。
カラー版はARMマイコン等(今月のInterfaceの付録)でやってみたいです。
AVR/PICの領域ではあまり触りたくないですね、欲深なので4096色以上を
望んでしまうので。（FPGAでええやんとか聞こえて来そうですが･･･
FPGAも面白いんですが、自分のPCでは論理合成に4時間とか掛かって
とてもお手軽とは言えない状況なもんですし)
>ドット単位の移動ってどんな風に実現しているんでしょうかね？
↓ネタバレ
while( vcnt ){
BYTE dat = pgm_read_byte( chr++ );
dat>>=ofx;
*pcg++ |= dat;
vcnt--;
}
特に高等な技術は使っていませんけど。
>１ＫＢのＳＲＡＭ
memory map
0x100 - working
0x200 - VRAM CODE
0x300 - PATTERN
0x400 - TEXT
0x480 - SOUNDwork
0x4C0 - stack
現在こんな感じですね。
Unknown
(
うだがわ
)
2009-04-06 22:16:44
ビデオとROM更新しました。
音楽を差し替えて雰囲気はぐっと向上したように思います。
ISPはスレーブとしてTimer0のOC0AとかでSPIのCLKを供給すれば任意のドットレート
に設定できますかね。 出力はスレーブ側のMISOを利用することになりますが。
今回は現状のままでとりあえず完成させて、その後じっくりと改造します。
Unknown
(
うだがわ
)
2009-04-06 22:16:48
ビデオとROM更新しました。
音楽を差し替えて雰囲気はぐっと向上したように思います。
ISPはスレーブとしてTimer0のOC0AとかでSPIのCLKを供給すれば任意のドットレート
に設定できますかね。 出力はスレーブ側のMISOを利用することになりますが。
今回は現状のままでとりあえず完成させて、その後じっくりと改造します。
Unknown
(
nekosan
)
2009-04-07 00:09:18
＞ISPはスレーブとしてTimer0のOC0AとかでSPIのCLKを供給すれば任意のドットレート
＞に設定できますかね。 出力はスレーブ側のMISOを利用することになりますが。
物凄いことを考えますね！
うーん。確かにそれならタイマーから出力するクロックに従ってＳＰＩのシリアル出力が行われるでしょうからクロックは自由自在かと思いますが、一方ＭＩＳＯから出力するデータをセットするタイミングって、結構シビアになりそうですね。ちゃんとタイミング守らないと２バイト同じデータを出力しちゃうとか。
あと、表示期間中と非表示期間中、両方ともシリアルクロックが入力される（タイマーを止めなければ）と思うんですが、その辺りの制御も色々厄介かも…
いずれにしても、分周比＝２＾ｎに従う必要はないでしょうから、その点での自由度は高くなるでしょうね。
ムービー、音色がオリジナルと見分け（聴き分け？）がつかない…
これってやっぱりＰＷＭで矩形波出力なんですか？
Unknown
(
nekosan
)
2009-04-07 01:17:25
一つ思いつきました。
あらかじめ、ドットイメージを横方向に引き伸ばしておけば良いかも。
よこ3ビットで1ドットにするとか。
（メモリとか凄くムダになりますが…）
Unknown
(
うだがわ
)
2009-04-07 05:32:03
>ちゃんとタイミング守らないと２バイト同じデータを出力しちゃうとか。
表示処理は他にすることが無いので、消費クロックは安定してますし大丈夫
かと思います、またバイト境界付近でTCNT0を読めば補正も可能でしょうし
問題ないかと思います。
>これってやっぱりＰＷＭで矩形波出力なんですか？
あ、そうです、オリジナルからwavetableも拝借しています。
Unknown
(
うだがわ
)
2009-04-07 06:28:56
TIMER2をclkI/O駆動すれば、TIMER0と同様に使えそうなので、
CTC動作を常にTIMER0の8倍の値を入れるようにすれば、
TIMER2のOCIE2Aチェックで行けそう。
5clk/Dotの場合
OCR2A = 5*8 - 1;
OCR0A = 5 - 1;
BYTEDATA = pgm_read_byte(chr++);
TCNT2=1
TCNT0=0
SPDR = BYTEDATA;
do{
___BYTEDATA = pgm_read_byte(chr++);
___do{
______BYTE tmp = TIMSK2;
______TIMSK = tmp;
______if(tmp & 1<<OCIE2A) break;
___}while(1);
___SPDR = BYTEDATA;
}while(...);
こんな感じで何とか行けそう、連投すいません。
Unknown
(
nekosan
)
2009-04-07 22:05:00
＞あ、そうです、オリジナルからwavetableも拝借しています。
うーん、ということは、各音階の音色データ（単音）だけサンプリングしておいて、それを音階のデータに従って再生している感じでしょうかね？
結構処理負荷を食いそうですねぇ。
Unknown
(
うだがわ
)
2009-04-10 22:55:36
こんばんは、
色々とISP絡みを検討しましたが、スレーブに設定すると
兼用端子等が潰れてしまい弊害が多いので諦めました。
あと、フィールドが狭かったので大改造を行い、やっと
安定しました。内部のポインタの扱いが大きく変わった
のでほぼ全面的に書き直しになってしまいました。
（見た目はあんまり変わっていませんけど･･･）
一応、ROM内容の更新を行いました。
Unknown
(
うだがわ
)
2009-04-11 23:34:57
おばんです、RAMが色々と厳しくなって来ました･･･
果たして完成するのでしょうか。
↓進捗(WMV:13MB)
http://www7.big.or.jp/~kerokero/avr/pactest.wmv
Unknown
(
nekosan
)
2009-04-12 00:33:23
＞おばんです、RAMが色々と厳しくなって来ました･･･
＞果たして完成するのでしょうか。
うーん。ほぼ完成って感じに見えますねぇ。っていうか、色を除くとオリジナルのテイストそのまま、。迷路の作りもオリジナルとそっくりですねぇ！ フルーツまで…。よくぞＣでここまで…
あと残るは得点表示、衝突時の処理くらいでしょうか？
ＩＳＰは…無理して使用せずとも、ドットピッチの自由度を優先させたほうが面白そうですね。
Unknown
(
うだがわ
)
2009-04-12 07:27:27
>うーん。ほぼ完成って感じに見えますねぇ。
ありがとうございます･･･
残り3KBで、ステージ間のcoffebreakとか諦めなきゃならんかな、
あ、でもFIELDマップをベタで置いてるので圧縮でも掛けますかね。
RAMもあと3BYTEしか空いていないので、スタックを調査して詰めんとならん、
スコアやらモンスターのアタックシーケンスが書けません。
思ったよりも一通処理やらワープゾーンの折り返しでコードや
処理時間を消費ってしまいました。 タイトルも入れたいし、
まだまだやる事は一杯残っておりますです。
Unknown
(
nekosan
)
2009-04-12 22:46:19
邪道技！
Ｉ２Ｃメモリを外部に積んで、アクセス速度に拘らないデータは外出しにしちゃうとか…。
マップなども元々そんなに大きいデータではなさそうですから、ＣＯＤＥＣ処理のロジックを積んだらはまりそうな…
３バイトに３Ｋバイトですか…厳しいですね…。Ｃｏｆｆｅｅブレークはグラフィックデータがでかいですからね。
Unknown
(
うだがわ
)
2009-04-13 23:29:00
>Ｃｏｆｆｅｅブレークはグラフィックデータがでかいですからね。
あ、一応キャラは既に登録はしてあったんですけどね。
ただRAMが足らないので、片っ端からビットフィールドやユニオンの
定義にしていったら、コードサイズが1Kバイトも増えてしまいました。
敵シーケンスとハイスコア登録（EEPROM対応）ネームエントリーを
終えたらVer1.0としたいと思います。今週末には一応完成を目指します。
Unknown
(
nekosan
)
2009-04-14 23:28:31
＞敵シーケンスとハイスコア登録（EEPROM対応）ネームエントリーを
終えたらVer1.0としたいと思います。今週末には一応完成を目指します。
30年程前、まさか1個500円程度のワンチップマイコンでパックマンができる日が来るなんて想像できませんでしたね！
楽しみです（^O^）
Unknown
(
うだがわ
)
2009-04-16 08:13:16
終盤に入り結構手間取っています。
ROMに詰込む作業でゲームとは無関係の作業ばかりになっています。
データの再配置やunion定義による意図しないメモリ破壊によるバグ等
で悩んでいます、デバッグコードを入れる隙間もなくなっているので、
何が原因なのか特定できないという･･･
デバッグコードの為に一部セクションを追い出すとバグらないという
悪循環、机上デバッグでガムバッテいます。
Unknown
(
nekosan
)
2009-04-16 19:44:34
＞デバッグコードの為に一部セクションを追い出すとバグらないという
悪循環、机上デバッグでガムバッテいます。
スタックが瞬間的に振り切れてたりするんでしょうかねぇ？
最適化オプション次第では、ソースコード上の1行1行で止めて観察できないので、どこかのステートメントの処理中に瞬間的にオーバーしているところがあってもシミュレーションが停止できないステートメントのところだとするとシミュレータ上ではわからないでしょうからねぇ。
破壊されているメモリの場所はスタック領域に近かったりします？
最適化レベルを最低にしておいて、大容量のコア（ＭＥＧＡ６４４とか）でコンパイルしなおし、シミュレータ上でアタリを付けてみるとかできませんかねぇ？原因究明のヒントにはなるかなぁ…と。
最適化オプションが変わっちゃうと、使用するスタックの深さも変わっちゃうかなぁ…やっぱり。展開後のアセンブラソースレベルでシミュレーションできればいいんですけどね…
Unknown
(
うだがわ
)
2009-04-16 21:22:55
シミュレーターも映像が出ないと厳しいので、Mega64をオーバークロックで使用
した方が早いのかも知れませんね。今、苦しんでいるのはメモリーの使いまわしで、
下のような定義をしているのですが。
union{
__struct{
____BYTE work1[10];
____BYTE work4[20];
____BYTE work7[30];
__}partA;
__struct{
____BYTE work2[12];
____BYTE work5[12];
____BYTE work8[36];
__}partB;
__struct{
____BYTE work3[20];
____BYTE work6[20];
____BYTE work9[20];
__}partC;
}work;
スタックと違いスコープがハッキリしないのと、メモリの一括クリアが出来ない
のでゴミが残ることや、別セクションに引き継ぎたいデータがあっても、
スタックを経由しないと運べないことですかね。
このため、割込みを止めたり、一旦浅い部分(スタック的に)まで戻ってから
１５パズルの様にデータを引き継いでいます。
お陰で可読性の悪いコードになって泣き入ってたりします。
ま、頑張ります。
Unknown
(
nekosan
)
2009-04-19 00:52:52
こみいったペリフェラルを使ってないのであれば、メモリが大きいコアを使って実験してみるのも良いかも知れませんね。
特にアセンブラならかなりの互換性が期待できるような気がします。原因究明の役に立つかも…
Ｃ言語だと、インクルードファイルがチップによってずいぶん違うかもしれないので微妙ですが… まぁ、アセンブラでもインクルードファイルが異なるのは一緒ですが。
Unknown
(
うだがわ
)
2009-04-19 18:22:15
お世話さまです。更新しました。"AVR PACMAN" 0.86 最終かもｗｗｗ
VRAM位置やスタックの調整、
ROMの隙間利用と一連の調整に無駄に時間を割かれましたが、
とりあえずひと段落です。でかいswitch文をFuncに変えたり
色々と手を尽くしましたがコレといった容量改善は見られなかったので、
これ以上の要素追加は次のグレードMega328以降となりそうです。
ソース書いてるよりも吐かれたasmファイル見てる方が圧倒的に長かった。
nekosanさんには色々と情報を頂きましてありがとう御座いました。
それでは失礼致します、また今度よろしくお願い致します。
Unknown
(
nekosan
)
2009-04-20 20:49:47
＞nekosanさんには色々と情報を頂きましてありがとう御座いました。
＞それでは失礼致します、また今度よろしくお願い致します。
いえ、何もお手伝いできませんで…
それにしても、１６ｋＢのワンチップマイコンにビデオ表示からパックマンのアプリケーションまで詰め込んでしまうとは…
見事ですね。
そうそう。ストロベリーリナックスに
http://strawberry-linux.com/catalog/items?code=18085
４２０円でアナログコントローラがありました。使ってみたいなと思っています。
Unknown
(
うだがわ
)
2009-04-27 21:07:39
PS2パッドにようやく対応。
受信側だけ早々に仕込んでいたつもりでしたが、Windowsからバイト転送し
ただけで動作確認したつもりになっていましたが、PS2パッド側の開発を終えて
実際に接続してみたらカドを曲がれないバグがあったので、遅れて修正。
PS2パッド変換は昔から情報があったので楽に終わると思ったら、
意外とトラップが多かったですわ。ビット反転等々。
とりあえずまともに動いたので良しとしましょう。
そういえば、nekosanさんから千石のスイチの情報貰ってましたね。
今度は逆にPS2パッド側を作ってPS2に繋いでみましょうかねぇ。
Unknown
(
nekosan
)
2009-04-27 23:59:22
ＰＳ２パッドですか…。私も以前情報収集して、実験してみようかと思っていたんですが、いまだ実現してません…
コントローラーの良し悪しは重要ですからね！選択肢がたくさんあるｉ／ｆ規格が吉ですね。
ちなみに４方向入力ができるタクトスイッチはマルツです。
https://www.marutsu.co.jp/user/shohin.php?p=62274
感触としては、デジカメの背面操作パネルの４方向ボタンみたいな感じです。（まだ使ってないので詳細を語れるほど解ってませんが）
コメントを投稿する
名前
タイトル
URL
コメント
※絵文字はjavascriptが有効な環境でのみご利用いただけます。
▼ 絵文字を表示
携帯絵文字
リスト１
リスト２
リスト３
リスト４
リスト５
ユーザー作品
▲ 閉じる
コメント利用規約
に同意の上コメント投稿を行ってください。
コメント利用規約に同意する
数字4桁を入力し、投稿ボタンを押してください。
ttp://www7.big.or.jp/~kerokero/avr/rsmoni(m168-20M).lzh
自分も今日試しました。
32*16が精一杯でした。
３２×１６まで行きましたか！って、テキストＶＲＡＭだけで内蔵メモリ一杯一杯じゃないですか！
とうことは、表示用のＶＲＡＭ（ドットイメージ）はレジスタだけで済ませているんでしょうかね？
いや、あれかな？１文字１文字個別にデコード…？
うーん、お見事です！ＭＥＧＡ８８／１６８ではまさに限界一杯一杯ですね。すごい。
RAMに展開して表示というのはしていません。
ROMから読んでそのままシフトして表示ですね、
ですからROMへの文字データの焼付けを一工夫しています。
ROMの3400-3FFFがデータです。
↓一応、証拠ビデオです。(26MB)
http://www7.big.or.jp/~kerokero/avr/rsmoni_test.mpg
ROMを焼いて動かすにも手間が掛かると思いまして^^
起動直後はスクリーンセイバーもどきです。
音痴なのは仕様ですので念のため。
ではでは。
うーん。しかも１１５２００ｂｐｓですか… 凄い。
制御コード用の特殊処理とか含めると１１５２００ｂｐｓは難しくなかったですか？
ＴＩＮＹ２３１３で以前作ったとき、スクロールをどうしても組み込みたかったんですが、これにだいぶ時間を取られてしまって、通信速度は適度に遅いものを選ばざるを得なかったんですよね…
もしかして、メロディーデータもＵＡＲＴから入力して鳴らしているんでしょうか？ここまで表現力があると、いろいろ応用できそうですねぇ。
＞ROMから読んでそのままシフトして表示ですね、
＞ですからROMへの文字データの焼付けを一工夫しています。
８ドット表示する合間にデコード処理をはさみこんでいる…という感じでしょうか？ハードウェア乗算器を上手く使うとこの合間に入りきるってことでしょうかね… 面白そうだなぁ。後でロジック考えてみよう…。
UARTは走査線割込み内でポーリングで読んでリングバッファ(64Byte)に蓄えます。
TEXTへの反映はメインループで処理しますので処理時間は気にしません。
CLSやスクロールも余裕ですね^^
メロディーはVB期間で割込み処理でこなしています。
音痴はDTMFによるもので、Dial3212333222399321233322321
となっています。（古いネタですいません）
ではよろしくです。
ＭＥＧＡ８８、ＭＥＧＡ１６８のｓｒａｍは１ＫＢですね。ｅｅｐｒｏｍの容量見ちゃってました…（^_^;）
６４バイトのリングバッファですか。なるほど。割り込み駆動でメイン側で処理するのであればスクロールも余裕かもしれませんね。
262本×60フィールド×10ビット＝157200bpsまで可能ってことで、115200ｂｐｓなら処理し切れますからね。
VT100互換に使えちゃうかも…
>２５０円で手に入るご時世だし。
入手性でMega88に移植した方が良いのかな・・・
あ、是非nekosanさんにトライして欲しいかも
表示位置調整付き、VT100互換で是非。
よろよろ。
想定しているのは、玄箱のシリアルコンソールに直接繋いで使うような感じです。
玄箱起動メッセージのうち、1行の文字数が多い場合はなんとか処理しきれると思うんですが、数文字毎にスクロールするような場合が連続するとどの程度まで耐え切れるのか…
もっと過酷なのは、arduinoなどのマイコンに温度センサーとか繋いで、温度を数桁の数字+改行マークとしてモニターする場合、数バイト毎に改行することになるので…
ブロック転送処理の処理時間次第なんですが、このあたりは命令表とのにらめっこですね…。
テキストＶＲＡＭ1枚512バイトと仮定して、それを転送するのに必要な命令数はザックリ4×512≒約2000クロック程度でしょうか？20MhzのAVRでは水平同期2本分近い処理時間ですね。
ポストインクリメント付きのLDとSTで1バイトずつ読み書きしていく処理を想定しています。
Z80のレジスタペア（16ビット幅）のPUSH,POPに相当するような命令も無いですし…。ＳＲＡＭのあるアドレスから別のアドレスに直接転送する命令も無いみたいなので。
スクロールを放棄して、一番下まで行ったら一番上の行に戻るという逃げ方はあるかな… 無いなぁ。
私が作ったスプライト表示器の処理のように1本ずつ間引いて表示すれば、その隙間に処理していくことも可能だろうと思いますが…うーん。
内容のブロック転送は避けることが可能です。
テキストの改行処理は表示座標変更と1行32バイトの消去のみなので10μｓ程度で済みますよ。
最初、計算処理１バイト（８ドット）毎にオフセットの計算加味しないといけないとばかり思っていたんですが、よく考えたらせいぜい１ラインの先頭で１回やっておけば十分ですし、もっと言えば８ラインの間はオフセット値を再計算する必要も無いので、この方式なら問題ありませんねぇ。
昔の８ビット時代のＰＣが（当然ながら）ＶＲＡＭアドレスが固定だったので、固定観念になっていたんでしょうね。
処理能力上、最も気になっていたのがこのスクロールと画面クリアだったんですが、その辺りが解決ついて、私が悩んでいた障壁は大分クリアになった感じです。
ちなみにうだがわさんが挑戦した時にネックになったところはどのあたりでしたか？
最初１文字ごとにCGROMとしてのアドレス計算に時間が掛かっていて、
文字同士の間が空き過ぎて間抜けな表示になったことです。
どうにか最小限のコードでCGアドレスを得るかで、
CGをROMへ焼付ける際にインターリーブにして
アドレス計算を無くすまでが長かったです。
一応、最初のHEXをスクロールでの対応に変更しました。
と同時に8KBのレンジに収めたのでMega88でも動作確認できるかと思います。
（※Mega16とMega88でコード互換かの確認はしていません）
いや～、色々と奥が深いですね。
Nekosanさんの広い知識には関心させられます。
このあたりって、ビデオ表示ではなにかとついてまわる課題って感じですよね…。この辺りがやっぱりマイコンとＣＰＬＤ/ＶＨＤＬとの違い…みたいな…。
私がＴＩＮＹ２３１３でテキスト表示やったときは、文字がデカかったので間が空いててもあまり気にしなかったのですが（＾_＾）。というか、そもそも１ラインがデコード（ビットイメージ作成）、次の１ラインが表示だけという手抜きッぷりですが…
ムービーではかなり細かい文字を表示されていたので、あの感じだと文字と文字の間はせいぜい１０クロック以内じゃないかと思うんですが、その程度でテーブルサーチ（？）完了しているっていうのが驚異的だなぁと思います。
↓こんなものを作っています。
http://www7.big.or.jp/~kerokero/avr/pactest.mpg
↓ROM
http://www7.big.or.jp/~kerokero/avr/pactest(m168-20M).lzh
忙しくならなければ今月中に完成させたいです。
板違いですいません。
ってことは無いですね。見た感じ、表示処理部分はほぼ出来上がりって感じですね。迷路もちゃんと綺麗な曲線で組まれていて、いい雰囲気です。
テキスト文字表示と比較して、ドット単位で位置をずらさないとならないスプライト表示って、タイミングかなりきびしくないですか？
私はデコードと表示を両立できなかったので、仕方なく1ライン置きにデコード行と表示行って具合に分けちゃったのですが…
とにかく、完成頑張ってください。応援してます。
あ、そうそう。この間マルツのメールマガジンで
https://www.marutsu.co.jp/user/shohin.php?p=62274
こんなの見つけました。一応入手だけしてまだ使ってませんが、もしかしたら入力デバイスとして結構使えるかも…
4方向としか書いてないのでナナメに入るのか微妙だったり、表面実装なのでかなり小さかったり…と。
でも単価１８９円はなかなかかと。
リンク先の内容は更新してあります。
リ○○ラ○○の曲。pacは曲でないのでPGから叩かないとならないので、
とりあえず走行テストの為に入れています。
>スプライト表示って、タイミングかなりきびしくないですか？
むちゃ厳しいですよ。横に太るのでもう1ck削りたいのですが、
今のところ限界です。もぅ自分の頭ではどうにもできません。
>とにかく、完成頑張ってください。応援してます。
あ、ありがとうございます。
何とか完成させたいです。 でも懸念材料は一杯ありまして、
・スタックマージン
・ＲＯＭ、ＲＡＭの残量
・処理時間
・バグ(スタック溢れ？)
色々とコンパイラと相談しながらチマチマ進めていますが、
以外とコンパイラさんが機嫌悪く、
こちらの望んだコードを吐いてくれません;_;
>こんなの見つけました。
あ、いいですね、タクトＳＷの寄せ集めは結局指の位置を
目で確認してしまうので、十字は一体型がいいですよね。
操作できるようにしたら試してみます。
あ、バグで壁が壊れて出ていってしまった>monster orz
それではまた。
先日のテキスト文字表示がベースになっているとしたら、あらかじめ１ドットずつずらしたパターンを必要数だけ用意しておいて、そのコードをテキストＶＲＡＭ上に置いていく感じなのかなぁ…と想像していたのですが…
それとも、リアルタイムでスプライトのＸ、Ｙ座標から画像の重ね合わせ処理をやっているんでしょうかね？
＞こちらの望んだコードを吐いてくれません;_;
アセンブラじゃなかったんですね…。あらためてびっくり！
そういえば、以前後閑さんがＰＩＣでＳＰＩの出力端子を使ってビデオ表示してましたね。
http://www.picfun.com/app24Fframe.html
シンクロがPB1（PWM?）、映像がPD7のようなので、映像信号は1ドットずつ書き出しているように見えるのですが、後閑さんのような方法にするとソフトウェア上は少し余裕が持てるかも知れませんね。
…ＳＰＩだと完全にシリアルなので、多段階の濃淡やカラー表示には向かないのですが…
SPIですか確かに8bitずつハード的な補佐が入ればかなり楽になりますね。
こちらの望んだボーレイトに調整できるのか分かりませんけど、
全く頭に無かったので検討してみたいと思います。
カラー版はARMマイコン等(今月のInterfaceの付録)でやってみたいです。
AVR/PICの領域ではあまり触りたくないですね、欲深なので4096色以上を
望んでしまうので。（FPGAでええやんとか聞こえて来そうですが･･･
FPGAも面白いんですが、自分のPCでは論理合成に4時間とか掛かって
とてもお手軽とは言えない状況なもんですし)
>ドット単位の移動ってどんな風に実現しているんでしょうかね？
↓ネタバレ
while( vcnt ){
BYTE dat = pgm_read_byte( chr++ );
dat>>=ofx;
*pcg++ |= dat;
vcnt--;
}
特に高等な技術は使っていませんけど。
>１ＫＢのＳＲＡＭ
memory map
0x100 - working
0x200 - VRAM CODE
0x300 - PATTERN
0x400 - TEXT
0x480 - SOUNDwork
0x4C0 - stack
現在こんな感じですね。
音楽を差し替えて雰囲気はぐっと向上したように思います。
ISPはスレーブとしてTimer0のOC0AとかでSPIのCLKを供給すれば任意のドットレート
に設定できますかね。 出力はスレーブ側のMISOを利用することになりますが。
今回は現状のままでとりあえず完成させて、その後じっくりと改造します。
音楽を差し替えて雰囲気はぐっと向上したように思います。
ISPはスレーブとしてTimer0のOC0AとかでSPIのCLKを供給すれば任意のドットレート
に設定できますかね。 出力はスレーブ側のMISOを利用することになりますが。
今回は現状のままでとりあえず完成させて、その後じっくりと改造します。
＞に設定できますかね。 出力はスレーブ側のMISOを利用することになりますが。
物凄いことを考えますね！
うーん。確かにそれならタイマーから出力するクロックに従ってＳＰＩのシリアル出力が行われるでしょうからクロックは自由自在かと思いますが、一方ＭＩＳＯから出力するデータをセットするタイミングって、結構シビアになりそうですね。ちゃんとタイミング守らないと２バイト同じデータを出力しちゃうとか。
あと、表示期間中と非表示期間中、両方ともシリアルクロックが入力される（タイマーを止めなければ）と思うんですが、その辺りの制御も色々厄介かも…
いずれにしても、分周比＝２＾ｎに従う必要はないでしょうから、その点での自由度は高くなるでしょうね。
ムービー、音色がオリジナルと見分け（聴き分け？）がつかない…
これってやっぱりＰＷＭで矩形波出力なんですか？
あらかじめ、ドットイメージを横方向に引き伸ばしておけば良いかも。
よこ3ビットで1ドットにするとか。
（メモリとか凄くムダになりますが…）
表示処理は他にすることが無いので、消費クロックは安定してますし大丈夫
かと思います、またバイト境界付近でTCNT0を読めば補正も可能でしょうし
問題ないかと思います。
>これってやっぱりＰＷＭで矩形波出力なんですか？
あ、そうです、オリジナルからwavetableも拝借しています。
CTC動作を常にTIMER0の8倍の値を入れるようにすれば、
TIMER2のOCIE2Aチェックで行けそう。
5clk/Dotの場合
OCR2A = 5*8 - 1;
OCR0A = 5 - 1;
BYTEDATA = pgm_read_byte(chr++);
TCNT2=1
TCNT0=0
SPDR = BYTEDATA;
do{
___BYTEDATA = pgm_read_byte(chr++);
___do{
______BYTE tmp = TIMSK2;
______TIMSK = tmp;
______if(tmp & 1<<OCIE2A) break;
___}while(1);
___SPDR = BYTEDATA;
}while(...);
こんな感じで何とか行けそう、連投すいません。
うーん、ということは、各音階の音色データ（単音）だけサンプリングしておいて、それを音階のデータに従って再生している感じでしょうかね？
結構処理負荷を食いそうですねぇ。
色々とISP絡みを検討しましたが、スレーブに設定すると
兼用端子等が潰れてしまい弊害が多いので諦めました。
あと、フィールドが狭かったので大改造を行い、やっと
安定しました。内部のポインタの扱いが大きく変わった
のでほぼ全面的に書き直しになってしまいました。
（見た目はあんまり変わっていませんけど･･･）
一応、ROM内容の更新を行いました。
果たして完成するのでしょうか。
↓進捗(WMV:13MB)
http://www7.big.or.jp/~kerokero/avr/pactest.wmv
＞果たして完成するのでしょうか。
うーん。ほぼ完成って感じに見えますねぇ。っていうか、色を除くとオリジナルのテイストそのまま、。迷路の作りもオリジナルとそっくりですねぇ！ フルーツまで…。よくぞＣでここまで…
あと残るは得点表示、衝突時の処理くらいでしょうか？
ＩＳＰは…無理して使用せずとも、ドットピッチの自由度を優先させたほうが面白そうですね。
ありがとうございます･･･
残り3KBで、ステージ間のcoffebreakとか諦めなきゃならんかな、
あ、でもFIELDマップをベタで置いてるので圧縮でも掛けますかね。
RAMもあと3BYTEしか空いていないので、スタックを調査して詰めんとならん、
スコアやらモンスターのアタックシーケンスが書けません。
思ったよりも一通処理やらワープゾーンの折り返しでコードや
処理時間を消費ってしまいました。 タイトルも入れたいし、
まだまだやる事は一杯残っておりますです。
Ｉ２Ｃメモリを外部に積んで、アクセス速度に拘らないデータは外出しにしちゃうとか…。
マップなども元々そんなに大きいデータではなさそうですから、ＣＯＤＥＣ処理のロジックを積んだらはまりそうな…
３バイトに３Ｋバイトですか…厳しいですね…。Ｃｏｆｆｅｅブレークはグラフィックデータがでかいですからね。
あ、一応キャラは既に登録はしてあったんですけどね。
ただRAMが足らないので、片っ端からビットフィールドやユニオンの
定義にしていったら、コードサイズが1Kバイトも増えてしまいました。
敵シーケンスとハイスコア登録（EEPROM対応）ネームエントリーを
終えたらVer1.0としたいと思います。今週末には一応完成を目指します。
終えたらVer1.0としたいと思います。今週末には一応完成を目指します。
30年程前、まさか1個500円程度のワンチップマイコンでパックマンができる日が来るなんて想像できませんでしたね！
楽しみです（^O^）
ROMに詰込む作業でゲームとは無関係の作業ばかりになっています。
データの再配置やunion定義による意図しないメモリ破壊によるバグ等
で悩んでいます、デバッグコードを入れる隙間もなくなっているので、
何が原因なのか特定できないという･･･
デバッグコードの為に一部セクションを追い出すとバグらないという
悪循環、机上デバッグでガムバッテいます。
悪循環、机上デバッグでガムバッテいます。
スタックが瞬間的に振り切れてたりするんでしょうかねぇ？
最適化オプション次第では、ソースコード上の1行1行で止めて観察できないので、どこかのステートメントの処理中に瞬間的にオーバーしているところがあってもシミュレーションが停止できないステートメントのところだとするとシミュレータ上ではわからないでしょうからねぇ。
破壊されているメモリの場所はスタック領域に近かったりします？
最適化レベルを最低にしておいて、大容量のコア（ＭＥＧＡ６４４とか）でコンパイルしなおし、シミュレータ上でアタリを付けてみるとかできませんかねぇ？原因究明のヒントにはなるかなぁ…と。
最適化オプションが変わっちゃうと、使用するスタックの深さも変わっちゃうかなぁ…やっぱり。展開後のアセンブラソースレベルでシミュレーションできればいいんですけどね…
した方が早いのかも知れませんね。今、苦しんでいるのはメモリーの使いまわしで、
下のような定義をしているのですが。
union{
__struct{
____BYTE work1[10];
____BYTE work4[20];
____BYTE work7[30];
__}partA;
__struct{
____BYTE work2[12];
____BYTE work5[12];
____BYTE work8[36];
__}partB;
__struct{
____BYTE work3[20];
____BYTE work6[20];
____BYTE work9[20];
__}partC;
}work;
スタックと違いスコープがハッキリしないのと、メモリの一括クリアが出来ない
のでゴミが残ることや、別セクションに引き継ぎたいデータがあっても、
スタックを経由しないと運べないことですかね。
このため、割込みを止めたり、一旦浅い部分(スタック的に)まで戻ってから
１５パズルの様にデータを引き継いでいます。
お陰で可読性の悪いコードになって泣き入ってたりします。
ま、頑張ります。
特にアセンブラならかなりの互換性が期待できるような気がします。原因究明の役に立つかも…
Ｃ言語だと、インクルードファイルがチップによってずいぶん違うかもしれないので微妙ですが… まぁ、アセンブラでもインクルードファイルが異なるのは一緒ですが。
VRAM位置やスタックの調整、
ROMの隙間利用と一連の調整に無駄に時間を割かれましたが、
とりあえずひと段落です。でかいswitch文をFuncに変えたり
色々と手を尽くしましたがコレといった容量改善は見られなかったので、
これ以上の要素追加は次のグレードMega328以降となりそうです。
ソース書いてるよりも吐かれたasmファイル見てる方が圧倒的に長かった。
nekosanさんには色々と情報を頂きましてありがとう御座いました。
それでは失礼致します、また今度よろしくお願い致します。
＞それでは失礼致します、また今度よろしくお願い致します。
いえ、何もお手伝いできませんで…
それにしても、１６ｋＢのワンチップマイコンにビデオ表示からパックマンのアプリケーションまで詰め込んでしまうとは…
見事ですね。
そうそう。ストロベリーリナックスに
http://strawberry-linux.com/catalog/items?code=18085
４２０円でアナログコントローラがありました。使ってみたいなと思っています。
受信側だけ早々に仕込んでいたつもりでしたが、Windowsからバイト転送し
ただけで動作確認したつもりになっていましたが、PS2パッド側の開発を終えて
実際に接続してみたらカドを曲がれないバグがあったので、遅れて修正。
PS2パッド変換は昔から情報があったので楽に終わると思ったら、
意外とトラップが多かったですわ。ビット反転等々。
とりあえずまともに動いたので良しとしましょう。
そういえば、nekosanさんから千石のスイチの情報貰ってましたね。
今度は逆にPS2パッド側を作ってPS2に繋いでみましょうかねぇ。
コントローラーの良し悪しは重要ですからね！選択肢がたくさんあるｉ／ｆ規格が吉ですね。
ちなみに４方向入力ができるタクトスイッチはマルツです。
https://www.marutsu.co.jp/user/shohin.php?p=62274
感触としては、デジカメの背面操作パネルの４方向ボタンみたいな感じです。（まだ使ってないので詳細を語れるほど解ってませんが）