投稿

10月, 2021の投稿を表示しています

6503がようやく動いた報告

イメージ
  回路図まで載っけて作りましたと宣言した前回。 いざ色々動かそうとしたものの、 プログラムがまともに動かないので試行錯誤してたら何年たってたんですかねこれ 。月日が経つのは怖いですね。 今回ようやく6503と6532が無事に動きました。 何につまづいたのかというと、多分アセンブラの文法です。 6502系のアセンブラって結構豊富で、 いろんなところから出てるんですがそれぞれアドレスの表記とか微 妙に違うんですね。 で、 今回久しぶりにca65というアセンブラを使用してみたのがつま づいた原因でした。 一度設定すれば大体の6502系には対応できるのが魅力ですが、 本当よくわからないmakeファイルの設定とかで地獄を見ました 。 以下何やってたのか簡単にまとめていきます。 新しい道具も作ったよ! ■:まず動かない いや、電気は通ってるしクロックは走ってるんですよ。 なのに6532の挙動がおかしくてIRQはでっぱなしだしcpu は止まるし訳がわかりません。 そこで今一度6532のデータシートを読むと、 「 NMIとIRQはオープンコレクタなので 必ずプルアップすること 」 ってあるんですね。何その罠。 というわけでプルアップ抵抗を追加しました。 これでcpuがすぐに止まる事故は解決… と思いきやまだ止まります。というか出力がよくわからない。 そこで大昔に作りかけてやめた出力確認用LEDパネルを作成する ことにしました。 ■:めちゃくちゃ便利なLEDパネル 5年くらい前にこんなの作ったら便利やろってLEDだけ並べて、 回路に不備があることに気がついてなげたもの。 今ならなんとかできそうってことで抵抗とトランジスタ をばーっと取り付けて、 カードエッジからも表のポートからも入力できるようにしました。 これまでは毎回ブレッドボードでled回路組んでたんでクソめん どくさいし抜けるしで散々だったのですが、 これで見やすい簡単出力もicに負担がなく万々歳になりました。 やったぜ。 まあ回路図書かずにえいやっと作ったので裏はすごいことになって ます。ちゃんと整えて、 入力スイッチもつけて体裁整えたら普通に便利道具になりそう。 クロックパルスも出せるようにしたいですね。 ledドライブのために2sc1815を贅沢に使用してます。 意外と高いですがいつ買ったのか結構あったので奮発...

久々に週刊MyRobot、ID-01を出して中を調べてみた。

イメージ
以前、家にある 変なロボット の記事を書きました。 このロボットなんですが、当時はどの部品がどういう仕事をしているのか正直モーターとセンサーぐらいしか分からずに組み立てていたのですが、今になってそれなりにわかるようになったため、試しにどういう部品が使われているのか、あわよくば今の技術でプログラミングできるのか調べてみることにしました。 ■このロボットのCPUはなんなのか? ID-01が発売されたのは2006年なので、もう10年以上前のふるーいCPUが積んであることは明白なのです。おまけにIntel系のノートパソコンとかに使用されているようなものは使用されているはずがないので(電池駆動ロボットで、そんな電気バカ食い発熱CPUなんて使用できるわけがない)、ちょっと中をひっさしぶりに調べてみることに。で、調べた結果、 モトローラ社のDragonBoll MX-1 (訴えられそうだな)というCPUが搭載されていることが判明。うん?モトローラ社?えーっとすごい聞き覚えがある。このブログにとても関係ある会社だと思ったら、MacintoshPlusに使用されているMC68000を開発した会社でした。さらに、このロボットで使用されているCPUはその68Kシリーズの後継CPUだったのです。 https://ja.wikipedia.org/wiki/DragonBall https://www.atmarkit.co.jp/news/200106/14/arm.html 発表はなんと2001年。とんでもなく古いCPUです。シリーズは今でも続いているようなのですが、速度とか色々不安になります。まあ期待する方がおかしいのですが。期待するならラズパイに置き換えるのが一番早い。 また、いわゆるAVRマイコンやPICマイコンと違い、プログラミング環境に難があります。というかなんのソフトを使用すれば書き込めるのか見当がつきません。当時のid-01のプログラミングツールを解析する必要があるでしょう。 ちなみにこちらがその当時のプログラミングソフトが入っているCD。プログラムは無事に動いたのですが、XPに特化したファイル構成&Javaインストール祭り&互換性で死にかけました。こう見るとやっぱり古いソフトなんですねぇ… ■音声認識モジュールについて このロボットの最大の魅力はなんといっても音声認識部分...

MZ80を起動せよ!画面バッファを利用した高速書き換えプログラム

イメージ
古いPCやゲーム機のプログラミングをしていると、その描画速度の遅さに四苦八苦することが度々あります。今回のMZ80もそうで、BASICで素直に描画するととんでもなく遅く、お話になりません。 そこで、アセンブラで描画処理の部分を描いてしまえばあとはどうにでもなるのでは?というかエミュレーターでテストできるならアセンブラでガリガリ書けば速度なんとかなるのでは? (MZ80のすごいところは、描画中にメモリアクセスのウェイトをかけていないことです。映像は乱れますが、強引かつ高速に描画を繰り返すことが可能です。) そう考えた結果、潤沢?なメモリを搭載しているMZ80のシステムを利用し、フレームバッファを用意して、スプライト画面・背景画面を合成、描画メモリへ転送するシステムを設計してみました。 メモリ転送とアドレス管理の考察 ■|そもそもMZ80はどうやってテキストを描画しているのか 上記の漫画にも記載したように、MZ80にはz80のメモリエリア上に画面に表示するテキストバッファが割り当てられている設計となっております。 そのメモリエリアはD000h~D3E7hまでの1000byteとなっております。 というのも、表示できる文字数が横に40文字、縦に25行となっているためですね。 そのため、疑似ドットグラフィックはこの2倍の(1文字に2ドット分配置されているため)縦50ドットx横80ドットの解像度として絵を表示することができるのです。 そして今のPCのようにラスターフォントで表示しているのではなく、VRAMには画面に表示するフォントのコードを書き込んでおります。そのため、任意のフォントグラフィックに書き換えて表示するといったような機能は搭載されておりません。  VRAMに書き込まれた文字コードがそのままグラフィックを記録しているROMにアドレスとして読み込まれ、フォントデータが出力される仕組みになっております。  そのため、搭載されているフォントグラフィックROMを差し替えれば、任意の文字グラフィックスに差し替えることが可能です。 ■|書き換え速度の問題と、VRAM転送問題  ゲームを作るうえでカギになるのはこの描画速度です。例えば、PRINT文で書き換えた場合は必ず1Fで1回しか処理されないため、描画速度がどうしても遅くなります。 ましてや、スクロール画面などの画面全体を書き...