2020年4月10日金曜日

ArduinoMega2560カードの紹介その後(完結編)

ArduinoMega2560カードが正常に動作するようになりました


前回、FM-7の40Pスロットで動作するArduinoMega2560カードを紹介しましたが、その際、動作後に6809に戻すためにはFM-7のメインRAMのリフレッシュ信号が必要であること。それをMega2560のソフトで実現したいが、なかなかうまく行かず、F-BASICに戻ってはくるがエラーメッセージが出てしまうという報告をしました。

そのブログを読んで下さったtomi9さんから、すぐに具体的なアドバイスをいただきました。

オートリフレッシュを用いる

それは、FM-7のDRAMであるMB8265はオートリフレッシュ(RFSH Refresh)でリフレッシュできるということ(など)でした。私のDRAMに関する知識は数十年前のもので、RASオンリリフレッシュでリフレッシュするものだと思い込んでおりましたので、まさに目からうろこでした。
早速そのようにプログラムを修正し、リフレッシュ信号などのパルス幅もできる限りデータシートの値に近づけてみました。

その結果、かなり動作が安定し、相変わらずエラーメッセージが出るものの、いつも同じエラーメッセージが表示されるようになりました。

Z80W信号がHighになることを確認する

さらにtomi9さんからの追加のアドバイスによって、Mega2560から6809へ復帰するために$FD05に0を書き込んだ後に、Z80W信号が実際にHighに変わるのを確認するためのwhile文を追加したことで、ほぼ確実に6809に戻ってくるようになりましたが、まだ、BREAKキーを押して戻す必要がありました。

ついに

その後、「思い付きハードで七転八倒」さんによる動作確認の結果やお二人からのプログラムの修正案をいただきながらプログラムの細かい見直しをした結果、ついに、常に正常に復帰させることができるようになりました。


連続実行の結果


ご覧のように、何回連続実行してもちゃんとF-BASICに復帰して、20行が実行されてLISTが表示されています。

FM-7の個体差か

しかし、私の2台のFM-7ではどちらも正常に動作しましたが、tomi9さんや「思い付きハードで七転八倒」さんのFM-7でも同様に正常に動作するというわけではないようです。
同じFM-7でも微妙な個体差があるようで、リフレッシュや6809への切り替え時のタイミングの調整で対応する必要があるということでしょうか。


資料

「思い付きハードで七転八倒」さんより提供された回路図を示します。


回路図


FM-7とMega2560の動作のシーケンスを下に示します。

動作のシーケンス

まとめ

FM-7の40Pスロットに他のボードを装着して動作させる場合には、6809がHALTしているので、ボード側でDRAMのリフレッシュを行なわなければならないが、それをソフトで行う試みについて報告しました。

この試みから得られた知見

(1)6809から別のCPUに制御を移した場合は、そのCPUでDRAMのリフレッシュを行う必要があるが、そのリフレッシュ方法としてはオートリフレッシュ(RFSH Refresh)が使用できる。
(2)6809から別のCPUに制御を移すには$FD05に1を書き込むだけで良いが、6809に戻すには$FD05に0を書くだけでなく、QB, EBの制御も必要。
(訂正:ご指摘を受けて間違っていることに気づきましたので、訂正します。戻るときも$FD05に0を書くだけで良いです。)
(3)同じFM-7という機種でも、このような場合には「個体差」が結果に影響することがある。
(追記:この手法そのものがFM-7には不適切なために「個体差」が影響したと言うべきでした。)

最後に、オリジナルのボードを考案されたFS-Micro Corporationさん、そのボードを目的に合うように改造され、動作確認やアドバイスを下さった「思い付きハードで七転八倒」さん、そして重要なアドバイスをいただいたtomi9さんの諸氏に感謝いたします。

なお、Mega2560ボードの回路図とスケッチはOneDriveで公開しております。


4 件のコメント:

  1. 桜井です。いろいろと試して頂いてありがとうございます。また、リフレッシュを失念しており、お手間をかけてしまい、申し訳ございませんでした。FM7は本来個体差は無い(ように設計する)ので、きちんと動作する回路を設計中です。まずはPICマイコン1個でリフレッシュを行う回路を考えたので、基板を発注済みです。基板ができあがり、試験が通りましたら送付させて頂きたいと思いますので、よろしければご連絡ください。試験は

    ①6809によりメモリにランダムパターンを書く
    ②Z80側に移行
    ③Z80側からは6809をアクセスしないで最低2分間待つ(待つ間にDRAMにドライヤーで熱をかける)
    ④6809に移行し、メモリパターンをチェック(チェックサム)

    を考えています。38年前にFM8や7のプロトタイプのDRAMをドライヤーで暖めながらこのような試験をしたことを思い出しました。リフレッシュを停めても数秒間は記憶していますが、徐々に00, FFのようなデータに化けて行きます。それこそ個体差があります。

    返信削除
    返信
    1. ちゃんと動作するものを作るためにはこのような試験をきちんとするものなのですね。DRAMをドライヤーで加熱するとは。。。
      数十年前に4116使用のメモリボードを製作した際には、リフレッシュのタイミングを74123で作ったためだと思うのですが、全範囲に$AAと$55を交互に書いては隣を読むというテストプログラムを走らせると、冬場は良いのですが夏になると2日間で1,2ビットほどのエラーが出て使い物にならずあきらめたことを思い出しました。
      のちほど連絡をさせていただきます。よろしくお願いいたします。

      削除
  2. ついでに記事にコメントさせてください。

    >(1)6809から別のCPUに制御を移した場合は、そのCPUでDRAMのリフレッシュを行う必要があるが、そのリフレッシュ方法としてはオートリフレッシュ(RFSH Refresh)が使用できる。
    おっしゃるとおり、Z80コネクタに*REFCK(CN9-B18)出力があり、これを使用するのでした。失念しており申し訳ございません。

    >(2)6809から別のCPUに制御を移すには$FD05に1を書き込むだけで良いが、6809に戻すには$FD05に0を書くだけでなく、QB, EBの制御も必要。
    QB, EBの制御とはどのようなものでしょうか。Z80側からはQB, EBを停止するだけで良いと思います。

    >(3)同じFM-7という機種でも、このような場合には「個体差」が結果に影響することがある。
    上にも書きましたが、個体差は有ってもそれを吸収するのが設計だと思います。基板が上がりましたら、確認をお願いしてもよろしいでしょうか?

    返信削除
    返信
    1. 桜井さまのご指摘を受けてプログラムを見直してみました。
      (2)ですが、おっしゃる通りZ80側から6809に戻る際にはQB,EBはLOWのままでした。リフレッシュの際にQB,EBを動かしていたので、それとごっちゃにしてしまいました。いい加減なことを書いてしまい申し訳ありませんでした。
      本文を訂正しておきます。
      (3)ですが、Z80側から6809に戻る際に、$FD05をLOWにしてからRWBをLOWにし、1msほどのdelayの後にRWBをHIGHにしているのですが、そのdelay値が私所有の2台のFM-7で適値が異なるのです。ということで「個体差」という言葉を使いましたが、おっしゃる通り、それを吸収するのが設計だと思いますので、このリフレッシュ法はその意味では不適切な方法だったと思います。

      桜井さまの新基板には期待しております。ぜひ動作を確認させていただきたいです。
      どのFM-7機でも動作するようになれば、秋田さまが目論んでおられますように、素のFM-7にプログラムを簡単に送り込むツールとして使えることになりますので、色々なことができるようになると思います。

      削除