TRY! CPM-68Kの巻き 2020.5.31

CP/M-80をつくるぞ!からの後半戦です)

まずは資料の収集です。CPM68Kに関連しそうなものを集めました。

BIOS作成に必要かも
(PCで動作)
アセンブラ(AS68k)
アセンブラ(その2)
アセンブラ(その3)
osソース SOURCE
CPM68KのOS
(各種バージョン)
CPM68Kver1.1バイナリ
CPM68Kver1.1バイナリ
CPM68Kver1.2バイナリ
CPM68Kver1.3バイナリ
CPM68Kのマニュアル類 CPM68K_PRROGRAMMERS_GUIDEL.PDF
CPM68K_USERS_GUIDE.PDF
CPM-68K_System_Guide_Jan83.pdf
CPM_68K_Technical_Manual_and_Installation_Feb84.pdf
アプリケーションなど cbasic
データシート TMP68301.pdf

まず、マニュアル類の中でシステムガイドがOSをインストールする主体の説明になります。

マニュアルを読むと、基本的にCPM68Kをインストールするには、近くにCPM68Kが動いているマシンがあるか、
あるいは指定したマシンがあることが主要な前提になっているのですが、一応周りになにもない場合についても
インストールの方法も書いてありました。勿論、これを試すことになります。

テーブルはどこだ?

 CPMの基本構成はCCP(Console Command Processor)、BDOS(Basic Disk Operationg System)そして
BIOS(Basic Input / Output Subroutines)になります。これらをまとめてCPM.SYSというファイルにまとめる必要が
ありますが、まとめるにはCPM68Kを動かすことが前提となります。そこで、最小限のシステムとして動かせるように
CCPとBDOSをまとめたバイナリー(Sフォーマットに入っている)がCPM15000.SRに入っています。
これはアドレス$15000から始まるもので、ちょうど128kByteのRAMでも動くようになっています。で、それにこちらで
作ったBIOSを追加すれば動くことになるのですが、CCPとBDOS、そしてBIOSの相互に参照するためのアドレス
テーブルが必要になります。マニュアルには、READMEかリリースノートに書いてある、とあります。

 しかしながら、ディスクデータの中をみてもREADMEはありません。またマニュアルにはリリースノートはありません。
リリースノートをネットで探しますが、どうも見当たりません。 ああああ・・・ここでいきなり挫折?という気になりました。

ここに書いてある!
なんともわかりにくいところに書いてあることがわかりました。おなじくCPM15000.MAPという
なにやら変数やジャンプテーブルラベルの一覧があり、それを参照しろということらしいです。

・・・・
gouser    19B78 global text
_load_tb   1A316 global bss
init_tbl    19BD0 global text
stack    1A97E global bss
_init     1B000 equ global abs
_sub_ind   1A980 global bss
_log_dsk   1A982 global bss
_load_tr   1A984 global bss
_gbls 1   A986 global bss
_crit_ds   1AA74 global bss
・・・・

こんな感じでテーブルがずらずら並んでいます。


おそらく必要になるのは、下記になるでしょう(ver1.3の場合。他のバージョンでは異なる)。
cpm 15000  ・・・・・CPMの先頭アドレス
_bdos 150CA ・・・・・BDOSの先頭アドレス(これは使わないかな?)
_ccp 150BC ・・・・・CCPの先頭アドレス(これはWARM BOOTでつかうはず)
_init 1B000  ・・・ BIOSの_INITのエントリーポイント(これが重要)

BIOSを検討していきましょう

必要な定数もわかったことなので、BIOSを検討していきましょう。
一番面倒なのはSDカードをディスクに見立てたアクセスルーチンです。CPM80のときに作りましたが、
完全に忘れているのでおさらいからです。

ところで、SDカードに昨年ALIで不良品をつかませられたものがあるのですが、
ひょっとしたら容量は小さくてもよいので、SDあるいはSDHCのどちらかでつかえないかな〜とおもって、
カードのチェックプログラムをPICに書き込んでしれべてみました。
どうせ、つかったとして数MB〜20MB程度です。それ以上あっても、使いきれません。

結果は、SDカードでもなく、SDHCカードでもないという返り値が戻ってきました。

やっぱり、真性の不良品だあ〜!!! ちょっと出鼻をくじかれました。
SDあるいはSDHCカードから調達に入らないといけなくなりました。


やっぱりつかえなかったSDカードです。 お気楽雑記帳2019(No.59)

まずは68KとPICとの通信から 2020.6.1

MC6800でのBIOSの処理のほとんどはPICに任せますが、そのやり取りを決める必要があります。
パラメータの受け渡しはSRAMを経由して行いますが、その処理の流れは別途2本の通信線で行うこととします。


MC68000とPICとの信号の流れです。

手順としては
 @MC68000側はパラメータをSRAMに書き込んだ後に、PICにBIOS処理リクエストを送信
 APICはリクエストを受け取った処理を行い、SRAMに返答用のパラメータを書き込み。
  そして処理済み応答を返す。
 BMC68000はPICからの処理済み応答があったことを確認して、処理リクエストを解除。
 CPIC側はリクエスト解除を確認したら、処理済み応答を解除


これが一連の流れになります。

信号受け渡しの手順です。

この一連の流れを一応、簡単なプログラムを書いて確認です。
ほとんど処理のない状態で、この一連のサイクルはだいだい13kHzの周期になるようです。
実際の処理の状況をモニターしていると、MC68000での応答了解(リクエスト解除)があってから、
PICによるリクエスト解除確認はほとんど瞬時なので、それをMC68000側で確認する必要はなさそうです。
その部分の処理を省けば少しでもサイクルタイムは短くできそうですが、全体が動いてからにしましょう。


手順どおりに動いていますね。

わからない???
CPM68Kの最初のシステムはCPM15000.SRCPM400.SRがありますが、どっちをつかうのがいいのだろう?
この数字の部分はCPMのDOSが開始するアドレスで、それぞれが$15000と$400を示しています。
CPM80のDOSはメモリーの一番後ろにあって、0番地からDOSまでの空間が使用できるメモリーとなるので、
条件的にCPM15000.SRを使おうと思っていました。そうすればメモリーの最初から$15000番地(約80kB)は使えることになります。
それに対してCPM400.SRの400って1kBのポジションですから、活用できるメモリーがないじゃないですか!
ひょっとして、ユーザがつかうメモリーの位置ってDOSの前でも後ろでもどちらでもいいのかな?それなら、CPM400.SRを使って
DOCをできるだけメモリーの最初の方に配置しておけば、それ以降のメモリーは自由に使えるわけですからCPM15000.SRより
使いかってはいいはずです。そう考えると、CPM15000.SRを用意する意味って何があるんだろう????
いまのところ謎です。

 とかまあ、こんなこと言っているレベルなので、本当にCPM68Kが動くところまでいくかどうか、かなり心配になってきました。


次のマイルストーン 2020.6.2

とりあえず次のマイルストーンを設定しておきまししょう。まずは、速度・容量は完全に無視してプロンプト A> がでるところまで
をめがけていきたいと思います。そのためには下記をすすめていきましょう。

1)BIOS(PIC側)の作成(C言語)
 とりあえず、ディスクアクセスの速度は考えない(SDカードの読み書きは512BYTE単位で、CPMの読み出し単位は128BYTEなので、
うまく扱えば、読み書きの速度があがりますが、当面考えない)。

2)MC68000側のBIOSの作成(アセンブラ)
 BIOSのサンプルが使えるように、ディスクの容量は8インチで片面単密度(240kB程度)で設定。

3)CPMディスクをSDカードに書き込み
 とりあえずDDT(デバッガ)あたりが動けばいいでしょう。

4)システムのロードは通信
 SDカードにシステムをいれて、それをロードするのもまずはハードルがあるので、とりあえずSフォーマットレベルでSRAMに書き込む。
 ※最終的には、PICの容量に余裕があればシステム(DOS)は、PICに内蔵しておいて直接RAMにダウンロードするようにすれば、
  高速に起動できるでしょう。

動かない・・・

 1)〜4)を準備して、いよいよ起動です。PICでのモニタープログラムから、制御のMC68Kに移しますが、見事に動きません。
原因を探るべく、BIOSコールがかかればPICに制御が移るので、そこで引き渡されるパラメータ(データレジスターD0〜D2)を
確認しますが,最初はD0=0(COLD BOOT)、次はD0=1(WARM BOOT)、そのあとは無茶苦茶な数字です。
最初にCOLD BOOTがBIOSでCALLされるのも変なのですが、ひょっとして動いているのだろうか?WARM BOOTがかかったら
CCPに制御が移るのだけど、それ以降がおかしいのかな??わからないな・・・・・。
 なにか根本的に間違えているのかもしれません。いや、根本的に知識が不足してるのかも(汗
ここで、この企画もおしまいになってしまうのかな〜とちょっとモチベーションダウンです。

悪戦苦闘・・・
 1.コードを追跡すべく、CPM68Kのシステムをすべて逆アセンブルしてコードを一から追跡します。でも、すぐに断念。
   だって、なにやってるかわからないし、それにいつになったら原因が判明するか・・・わかりそうにありません。

 2.フリーのMC68Kのシミュレータをインストール。でもその使い方がよくわからない・・・・・

 3.BIOSコール毎にCPUをリセットして、レジスターの値をチェック・・・・ん?おかしい?
   PICで認識するBIOSの機能NOと、MC68K側で送り出している機能Noが一致しません。これが原因か?
   
原因判明!
 簡単なバグでした。レジスターD0の値はメモリーを経由して引渡しますが、MC68Kでメモリーに書くときはLONG(32ビット)にしています。
 BIOSコールを受けてPICで読み出すときも陶然LONGで読み出したつもりが、WORD(16ビット)での読み出しになっていました。
 変数のビット数が異なるので、当然メモリーに格納される位置がずれていますから正常な値が引き渡されていなかったようです。
 ということでPIC側のCプログラムを修正です。
 今度は動くかな?

動いた???あれ?
 さて、PIC側プログラムを修正して再度起動に挑戦です。
 ををを! プロンプト A> がでました。こりゃ、動いていそうです。でも、エラーも同時にでています。
なにやら、例外処理の#3でユーザアドレスがなんとかかんとか・・・なんのことやら。
どうやらファイル名の一覧(DIR)もできないことから、ディスク関連のルーチンにバグが残っているのかもしれません。
でも、かなり前進です。

 
 なにかエラーが発生しています(例外処理の#3でのユーザアドレスの違反?なんのこっちゃ)

ちょっとやる気がでてきました。でも、遅いので早く寝よ!


デバッグは続くよ、どこまでも・・・・

エラーの原因を確認すべく、BIOSコールがかかった位置を特定していきます。
コンソールの入出力関係以外でBIOSコールがかかったら、システムを一時停止させます。
さて、何が原因かな?
 エラーの出る直前の呼び出しはDISK SELECTでした。
調べてみたら、パラメータの引渡しを間違えていました。とりあえず修正です。


エラーの直前はNO.9のBIOS機能呼び出しです。ここが怪しい・・・。

とりあえず修正して走らせてみました。今度はエラーはでません。
おそるおそる DIR と入力すると、ファイル名がでてきました。

多すぎる!
 たしか、ディスク(SDカードをつかっている)には2個程度のファイルしか入れていないのですが、
なんども同じファイル名が表示されています。まだまだ、バグがありそうです。
ただコマンドとして
A>DDT680000
と、叩き込んだらフリーズしてしまいました。
でも、一歩前進かな〜!!


修正したら、ディレクリがでるように????あれ、数が多すぎる。同じ名前がいっぱいあります。

今回のBIOSで、すこしややこしいのがBIOSからの戻り値をMC68Kに搭載したBIOS側で
行うのか、それとも一旦外部処理にまわすPIC側で行うかの混在があります。これも
間違いの要因でもあったので、すこし備忘録代りに整理しておいたほうが良さそうです。



BIOSとPICプログラムの再度見直し!

上記の表にもとづいて、BIOSを一旦整理です。どこか間違えている?ということはわかりませんが、とりあえず動かしてみましょう。
ん・・・・システムがフリーズすることはなくなりましたが、なんかエラーがでるな〜。
おそらく、ディスクのディレクトリが正しく読めてないことからファイルサイズがおかしくなっているのでしょう。

エラーは出ていますが、システムがフリーズすることはなくなりました。

次はなにをチェックしたらいいだろう?とりあえずディスクシステムをもう一度作りなおしてみるのと、
ディスクのREAD/WRITEのCプログラムをチェックしてみましょう。

さらにデバッグ・・・迷宮にはいりつつ????

色々と試しているが、だんだん症状が悪化しつつあるような・・・。
かたっばしから、状態を表示するようにしてみると不可解な現象が発生します。
 @頻繁に初期化が走る。CTRL-Cを押せば、普通はWARM BOOTのはずだが、なぜかCOLD BOOTになってします。
 A表示の途中でなぜか、キーの入力待ちが発生してします。
 BいきなりドライブJを選択しようとする。

実はBについては、ドライブ選択の機能NOが9なのと、ドライブ番号9がJなので、ひょっとして単純なミスだとおもわれるのですが、
何回ソースを見かえしても間違いはないようなのですが・・・・・

ちょっと頭を休めたほうがいいかな?

ああ、また半田ゴテで遊ぼうかな!と現実逃避、敵前逃亡です(笑。

一難去って、また一難! 2020.6.6

だんだんプログラムがぐちゃぐちゃになってきた上で、なにがなんだかわからなくなってきたところもあるので、
ここらでBIOSの一新と、PIC側のプログラムの構造を変えることにしました。
 いままでは、BIOS側での作業は最小限にしていて、BIOSコールが呼ばれたらほとんどPICにその処理を任せていました。
今回はBIOS側でできるだけの処理を行い、PIC側はどうしてもBIOSではできない処理だけを担当させます。というのも、
BIOSについてはサンプルプログラムがあるので、できるだけそれをつかったほうが確実かも、と思ったわけです。
で、その結果はすこし前進です。
 DIRを表示したときに、ファイルの数が合いました(笑。
 でも、肝心のコマンドが実行できません。


DIRによるファイルの表示は正常になりました。でも、コマンドが実行できません。

まだ、BIOSにバグがあるのか、それとも使い方が間違っているのか・・・・。
症状的には、CCPは動いているように思うのですが・・・・
まず、
 ・DIRでのファイルは正常に表示される・・・・SDカードへの保存はOK(DIR構造は間違っていない)。
 ・大きなファイルのTYPE(ファイル内容の表示)も問題ない・・ディスクの読み出しも問題ない。
 ・ファイル名の変更や、ファイルの消去も問題ない・・・・ディスクの書き出しも問題ない・

とりあえず、ファイルを扱うことは大丈夫なのですが、コマンドが実行できません。
まだ、やることが必要なのかな?

まったくわからいのは、RELという拡張子のついたファイルは再配置可能な実行形式のファイルのはずなのですが、
そのファイル名を拡張子無しで、例えばED(ファイルエディタです)と打っても反応しません。ファイルが無いと文句をいってきます。
そこで、拡張子までつけてED.RELとうったら、今度はエラーが発生します。
 ガイドブックには、拡張子まで打つようにとは書いてないんだけどなあ〜。ひょっとして、ファイルの属性を示す
何かが抜けているのだろうか?よぅやく動き出したのに!と思っていましたが、結構シリアスな問題にぶつかったかな〜。
 一難去って、また一難です。


EDは実行ファイルとおもうんだけど、EDと打っただけで起動しないの?

もうちょっとガイドブックを読んでみましょう。


んんん・・・・・ 2020.6.7

されに、PROGRAMMER'S GUIDEも印刷して、眺めていますがよくわかりません。
画面で見るとしんどいので、紙に印刷したら120枚もありました。
そろそろプリンタトナーが切れてくるころだなあ〜。

まあ、それはさておき、今後のデバッグに役立つかもしれないので、おかしな現象をピックアップです。

おかしな現象1
・テキストファイルをTYPEすると普通に表示される。 (これはOK)
・実行形式のファイルをTYPEするとエラーが発生する。 (これもOKなのかな?)
・次に、テキストファイルをTYPEするとエラーがでる。(これはおかしいのでは?)
 その他のDIRやERAなどのコマンドは問題なく実行できる。


一度エラーがでると、次からTYPEができない。

おかしな現象2
実行形式のファイルについては、そのヘッダ部分が決められています。


ED.RELの場合のバイナリーをみてみると、下記のようになっています。

ED.RELのプログラムヘッダ。16Hから始まるパラメータは0Hになっています。

気になるのが16Hからはじめる"テキストセグメントとプログラム実行の開始”が0Hになっていることです。
サンプルでは500Hになっていて、あたかもプログラムの開始アドレスになっていますが、MC68000で開始アドレスが
0Hというのはおかしいのだけど(0H〜400Hまでは例外処理ベクタが割り当てられている)、これでいいのかな〜?
たとえば、これを弄ったらうごくのかな。しかし、いちいちこれを弄るなんて、書いてないしなあ〜。
なんかプログラムで一括して変更できるようになっているのだろうか?謎だ〜。

他のプログラムをみては大体、0HだけどSTAT.RELは1000Hだったけど、これなら動くのかな?
でも同じくPIP.RELも1000Hだけど動かなかったなあ〜。

STAT.RELのプログラムヘッダ。こちらは16Hから始まるパラメータは1000Hです。

だんだん敗戦色が濃くなってきました・・・・・。
あとは、何ができるかな〜???


微速前進・・・・・

CPM80の三兄弟ができあがったこともあるので、再度このCPM68Kの見直しです。じつは、CPM80のデバッグにおいて、
重要な情報がえられたかもしれません。というのも、CPM80でテキストの表示はできるのだけれど、コマンドファイルの実行ができない
バグにぶちあたりました。このときの、バグの原因はティスクの読み書きのサブルーチンに問題がありました。その状態でも、
ディレクトリの表示は問題なかったこともあるので、このCPM68Kとかなり類似した症状です。ということで、まずは
ディスク周りを徹底的に見直すことにしました。

1)まずは、ディスク内容そのものが正常かどうか?
  CPMのディスクを作るにはCPMTOOLSというソフトを使っていますが、それをつかって作成されたファイルが正しいかどうかのチェックです。
 1つのコマンドファイルをディスクに書き込んで、再度読み出して同じ内容になっているかを確認です。これについては問題ありませんでした。
 まあ、ここで問題があるようだと、テキストファイルも正常に読めないでしょう。

2)ディスクの読み書きサブルーチンは大丈夫か?
  これも、何度も見直しました。が、問題はなさそうです。これも長いテキストファイルが正常に読めることを考えると、とくにバグはないでしょう。
 それより、バグのリスクを減らすために、ブロッキング・デブロッキングの処理は一切省いています。そのため、ディスクの読み書きの速度は
 かなり遅いです(そのかわりバグのリスクは少ない)。

どうやらディスク周りはでなさそう・・・・

こうなったら!
 アセンブラのソースを一行づつ、丁寧に見ていきましょう(もう何度もやった気がするけど・・・・。

あ!!!
 BIOSアセンブラを眺めていて、1箇所間違いをみつけました。BIOSコールのときの処理番号はWORD(16Bit)でパラメータが引き渡されますが、
 それをLONG(32Bit)で処理しているところがありました。WORDで処理するなら上位16BItは無視されますが、LONGだと上位16Bitも関係してきます。
 そこで、予め上位16Bitをマスク処理しておくことにしました。そして、再度アセンブルして実行です。

微速前進!!
 TYPEコマンドでテキスト表示をさせるときに、2回目の表示をさせようとするとシステムがフリーズする現象がありましたが、このバグの修正で
 直りました。何回TYPEコマンドを実行しても、フリーズすることはなくなりました。
  でも、あいかわらずコマンドファイルの実行はできません。相変わらず
[Insufficient memory or bad file header]
 なる、エラーがでてきます。でも、すこし前進しました。ほんの微速ですが・・・・・


動いた?

 こうなったら、面倒ですがBIOSがコールされる前に、引き渡されたパラメータと処理して引き渡すパラメータをすべて表示させてチェックです。
 すべてのBIOSコールをやると、画面が無茶苦茶になるのでコンソールの入出力以外での表示に限定します。
  で、最初の方にでてきた「GET ADDRESS OF MEMORY REGION TABLE」と呼ばれるBIOSコールの戻り値がおかしいことを発見です。
 本来はテーブルが格納されているアドレスである「0x1bb20」が返されるはずですが、そのままBIOSのコール番号「18」が返っています。
 どうやら、戻り値を間違えてオーバライトしている行があることに気づきました。ひょっとしてこれが原因だったのかな?メモリー範囲を示す
 テーブルが間違っていたらから、[Insufficient memory or bad file header]というエラーが発生していたことと辻褄があいます。
 で、早速修正して実行です!

 動いた!!!!
 
 PIPコマンドが実行できました。

 ををを!いままでエラーが出続けていた、コマンドファイルの実行ができるようになりました!!!
 これは嬉しい!
  おおきな前進です。

 かなりやる気がでてきました。 でも、夜も遅いのでここまでにしておきましょう(きりがない・・・。


次なるマイルストーン 2020.6.19
 つぎのマイルストーンの設定です。いまは標準のディスク構成(8インチ片面単密の240kB)なので、全然容量がたりません。
なんせCPM68Kは標準のディスクで9枚ものボリュームになります。
まずは、ディスク容量を増やすことも必要なのですが、現時点で動くプログラムにはバグチェックのための不要なルーチンがいたるところに
入っています。そこで、次なるマイルストーンは

 ・一旦すべてのプログラムを綺麗に(短く)整理
 ・ディスクの容量を拡大(1ディスクあたり2MBくらいで8ドライブで十分かな?)

まずは、ここまで進めましょう!その前に、いま仮にでも動いているプログラムを上書き修正すると、取り返しつかないことになりかねないので、
バックアップをとっておかなくっちゃ!


まずは一段落?
 とりあえず、プログラムの中から不要なものは排除してスッキリさせました。
あと、ディスクは8MBを4ドライブ分設けました。
これでCPM68Kのすべてのシステムファイルを1つのドライブに余裕をもって入れることができました。


1ドライブですべてのファイルが収まりました。

まだまだ腑に落ちません
 いままで動かなかったコマンドファイルも問題なく動くようになりました。


 一応、動くようになったと思うのだけど、わからないことが多々あります。
実行ファイルには拡張子が.68Kと.RELがあって、前者が絶対アドレス配置のもの、.RELが
どこにでもおけるものらしい(リロケータブル)。それはいいとして、実行するためのファイルのタイピングは、
拡張子が68Kのものは、ファイル名だけでよいが、RELの拡張子のものはファイル名と拡張子を両方いれないと
いけません。でも、ほとんどのコマンドファイルの拡張子はRELになっています。
 で、マニュアル見ると、コマンドファイルの実行はファイル名だけを入れるように指示されています。
ということは、ほとんどすべてのファイルは68Kの拡張子になっていないと駄目ということです。
 ひょっとしてRELを68Kに変換するコマンドがあるのだろうか?ひょっとしてこの作業は手作業?
まさかそんなことはないよね〜???

 とりあえず動くようになったのは前進なんだけど、まだまだ大切なことを見逃しているようです。
まだまだ調べなくては・・・・・


ちょっと使ってみる! 2020.6.20

だんだんわかってきました
 実行ファイルで拡張子のRELと68Kの違いは、前者がリロケータブル(どこでも配置可能)に対して、
68Kが絶対番地指定なのだが、それだったらRELだけでいいやん!と思っていたが、どうやら
実行速度とディスク容量が大きくちがうと書いてあった。
 実際に比べてみると、RELに比べて68Kの方が半分くらいの容量である。ということは実行にかかる
時間(ディスクの読み込み)も半分になるということなのですね。なるほど。

容量がRELと68Kでは倍半分と違います。CO68はCのコンパイラの一部です。

ということで、メーカからの配布版についてはRELとしておいて、ユーザ側でのメモリー配置は個別に
違うので、それらにあわせて68Kファイルに変換してください、ということのなのでしょう。しかし、
RELファイルって結構な数あるので、1個1個ほんとうに処理するのかな?
 ちなみにRELから68Kファイルに変換するには RELOC.RELというコマンドファイルを使います。
そのため、

A>RELOC.REL AS68.REL AS68.68K

といった作業を延々と繰り返す必要があります。途中面倒になってSUBMITファイルを書いたりしますが、
またエディターがラインエディター(ED)しかなくて、これがまた使いにく・・・というか全然使い方がわかりません。
せめてWM(ワードマスター)くらいのスクリーンエディターがないの?と思ってしまいます。

で、なぜこの作業が必要かというと、Cコンパイラを使おうとしたときに、すべて68Kファイルにしておかないと
SUBMITファイルが文句を言ってきます。なんせ、RELファイルで動くようには記述されていません。

ほんとに、CPM68Kをうごかしておられた人は、こんな面倒なこと(RELから68Kへ変換)をしたのでしょうか?
やはり謎だなあ〜。

とりあえず、

CPM68Kも動かしてみるということで、C言語で簡単なプログラムを書いて実行してみましょう!
これは、お約束のようなプログラムです。


これをコンパイル&実行してみましょう。

コンパイルとリンクを続けて行いますが、それにしてもパス数の多いこと!
リンクも含めて5パスです。たしか、このCは昔憧れのWHITE SMITHのCだったとおもったけど違うかな?
それにしても、わずかなプログラムですが、コンパイル&リンクになんと1分50秒かかりました。
おそらくSDカードのアクセスが遅いためでしょうが、これをフロッピーディスクでやったら、カップラーメンが
余裕でできそうです。


無事実行できましたが・・・・・遅すぎ!!!

もうちょっと、コンパイルが早いものがなければちょっと使うのはきついかも・・・です。
まあ、もともと動かすことが目的なので、これで何かをしようとはあまり思いませんが・・・・。

実用性を考えたらCPM80の方がいいかもです。処理速度はまけるでしょうが、コンパイル&リンクも結構早いので
プログラム開発には向いているでしょう。

でも、CPM68KもRAMディスクを使ったら超速になるかも。あと、2MBほどメモリをたせば、世界が変わるかも
しれません。 まさか、やる?やれば?←悪魔の囁きです(笑。

あ!備忘録です。
 Cコンパイラを動かす前に、アセンブラのAS68については初期化をしておく必要があります。
最初は、わけのわからないエラーがでて悩みましたが、マニュアルをみるとエラーの対処方法としての
初期化が書いてありました。

A>AS68.REL -I AS68INIT

で初期化をおこなうようです。

しかし、情報が少ない!
 CPM68Kを動かすにも、色々なHPを参考にすればいいかと簡単に思っていましたが、実際に検索しても
ほとんどありません。あったのはここくらい。→ https://piclabo.blog.ss-blog.jp/2018-07-22
Z80のCPM80だと、ちらほらあるのですが・・・・
 まあ、CPM80は8ビットのOSとして一世を風靡した感もあり、色々なソフトも充実していますから、
懐かしんで動かす人も一定の人がいそうです。それに対してCPM68Kはほとんど国内でも出なかったん
だろうな〜と想像します。当時は他にCPM86やMS-DOSもあったし・・・・。それに68000が動くPCも少なかったしな〜。

まずは、念願叶う!
 こんかいのCPM68Kを作った目的は、まずはそれを動かすことですが、なかでもCコンパイラを実際に動かすことが
一つのゴールでしたの、念願が叶いました。
 ここいらで、一旦お開きかな〜と思っていましたが、つい最近にALIに頼んでいたMC680000が届きました。
64PのDIPなのでかなり大きいです。これを目の前にすると・・・・また、半田ごてを握りたくなってしまいます(笑。

 
 直近でMC68000の16MHz版を入手しました。ああ〜どうしよう。


さて、あとは最終コーナです
 短いコーナだといいですが・・・。


最終コーナに入る前に・・・ 2020.6.21

RAMドライブを組み込んでみる!
 Cプログラミングでコンパイルとリンクで2分弱(それも最短で)というのは、なんぼなんでもかかりすぎです。
今回の目的がCPM68Kを動かすことではありますが、これでいいの?という感じがフツフツと沸いてきて、
やっぱりRAMドライブを検討してみることにしました。
 速度重視ですから、PICの制御は介せず、68000のBIOS内にサブルーチンを組み込むわけですが、
面倒かな〜と思っていたら68000には便利なアドレッシングがあることがわかりました。それが、これです。

MOVE.L (A0)+、(A1)+

この例ではA0アドレスの内容をA1アドレスの内容に移動し、その後にA0、A1レジスタの値をインクリメントします。
そして、ロングワードでの移動を指定してやればA0,A1は自動的に+4となります。この命令を使えば、
簡単にメモリーの内容を移動できます。CPMでは1セクターのデータ数は128なので、この命令をロングワード
で扱えば32回繰り返すだけでいいはずです。
 で、横着して32回のループを回すかわりにに、32個の命令を並べることにしました。これが、一番簡単!
プロからみたら「汚いプログラム!」っていわれそうですが、ミスも少なくなるし、それに高速です(笑。


データの移動は、ループを省略して同じ命令を32個並べました。回数を間違えないようにコメントに回数を入れています。

ちなみに、この1つのMOVE命令は20クロック必要です。1回の命令で4バイトの転送ですから、12MHzで動いている現在の
システムでの転送速度は、2.4MB/sになります。往年のCPUだからこんなもんかな?

さて、現状のRAMは全体で2MBありますが、このうち1MBをRAMディスクに割り当てることにしました。
1MBは切のいい数字で、128セクター×64トラック×128バイト/セクター=1MB なので、アドレスの計算もビットシフトだけで
できます。そのためプログラムは意外と簡単にできました。下手にセクター数を20とか30とかにしたら、掛け算が必要になるので、
間違える要因です。

組込み完了!
 BIOSを修正して、BドライブをRAMドライブに置き換えました。
STATコマンドで、1MBの容量が確保できていることを確認です。

まずはBドライブをRAMドライブにしました。

爆速?!
 さっそく、Cコンパイラを走らせてみました。必要なファイル類をすべてRAMディスクにコピーします。
1MBあったRAMドライブの残り容量は約500kBです。これだけあれば、結構なプログラムがかけるでしょう。
メインメモリは1MBに減ってしまいましたが、いまのところはこれで十分な処理はできるでしょう。
 で、肝心のコンパイルとリンクの実行速度は下記の通りです。もう、感激です。コンパイルのソース
内容は単純に「HELLO WORLD」をプリントする一行だけのものです。

SDカード上 RAMドライブ上
コンパイル 57秒 3〜4秒
リンク 46秒 11秒
103秒 14〜15秒

とくに嬉しいのがコンパイル時間が1/10以下に短くなっていることです。バグだしはここで行いますから、
何度も実行します。ここでの時間短縮はプログラム作成の効果があります。反面、リンクは1/4程度にしか短くなっていません。
ここはコンパイルが成功してから通すので、少々時間がかかっても許せます。リンクにRAMディスクの効果が
低いということは、CPUががんばって動いているということなんでしょう。

それにしてもRAMドライブにすると、各コマンドファイルの反応がものすごくいいので、ストレスがなくなります。
いままではコマンドファイルの読み込みに数秒かかるので、1テンポ遅れる感じがイライラの元でした。
しかし、まあ〜、これをフロッピーでつかっていた時代もあったわけですから、当時の人はストレスに強かったのでしょうね〜。
(私も含めて)現代人はストレス耐性が弱いのかもです(笑。

さて、この感激を味わってしまうと、もう元には戻れないな〜。やっぱりRAMディスクのために、さらにSRAM増設しようかな〜。

やっぱりあったんだ!
RAMドライブをつかって色々なファイルをコピーしているときに、一連のSUBMITファイルがあることに気づきました。
中身をみると、RELファイルから68Kファイルに変換するためのコマンドが並んでいます。やっぱり、1個づつ人手で
やる必要はなく、まとめてできるようになっていたんだ!!!
 全然マニュアルとかにも書いてないし・・・まあ、この手のものは書く必要がないのかもしれませんが・・・・
もっと便利なものがないか探してみよ〜

RELから68Kに変換する一連のSUBMITファイルが用意されていました。

ようやく最終コーナに入れるかな?


最終コーナへ!

さて、いよいよ最終コーナーです。

1)システムの再構築

なにをするかといえば、システムの再構築です。というの、
今のメインメモリーは1MBで使用(残りの1MBはRAMドライブへ)していますが、CPM68KのOS(CCP+BDOS)は
SR15000をそのままつかっているため、メモリーの真ん中に居座っています。

メインメモリー   : $00000  〜 $0FFFFF
OS         : $015000 〜 $01FFFF
使用可能エリア  : $020000 〜 $0FFFFF (約918kB)

そのため、すこし使えるメモリーエリアが無駄になっています。そこで、システムガイドに従って、OSの位置を
メモリーの後ろ側においやって、使えるメモリーの領域を拡大してやります。

最終的には
メインメモリー   : $00000  〜 $0FFFFF
OS         : $0F8000 〜 $0FFFFF
使用可能エリア  : $000400 〜 $0EFFFF (約982kB)


の形に変更します。もっとつめれば、さらに拡大できますがOSの配置はメモリーの切りのいい番地にしています。
まあ、単に境界の計算が面倒だったというだけです(笑。

手順は以下の通りです。
 1)CPM68Kのアセンブラ(AS68)でBIOSをアセンブルし、オブジェクトを作成する。
 2)リンカー(LO68)でCPMLIBとリンクしてリローケータブルなCPM.RELを作成する。
 3)SIZE68でCPM.RELのサイズを確認する。大体$6600くらいになります。
 4)RELOCでメモリー配置を絶対番地の$F8000にしたCPM.SYSを作成する。


本来は再配置を行ったOS(CPM.SYS)は、ディスク(SDカード上)に配置しておいて、立ち上げ時に
それを読み出してメモリーにロードする形でOSを立ち上げます。しかし、ここでは変則的にCPM.SYSの中身を取り出して
PICのROMの中に格納しておいて、直接メモリーに書き込む方法をとります。この方法はメリット・デメリットがあります。

メリット
  ・とにかく起動が早い。
  ・SDカードが壊れていても、とりあえずCPM68Kが立ち上がる(これが重要)。
  ・ブートローダ用のBIOSを作らなくてもよい(これも重要)。


デメリット
  ・作成がちょっと面倒。
    1)まずCPM.SYSをダンプコマンドでテキストエディターで編集できるようにする。
    2)テキスト編集して、C用のデータファイルに書き換える。
  ・BIOSの変更のたびにPICを書き換えないといけない。


まあ、BIOSを書き換えることもあまりないでしょうし、それに数年後に思い出したときにでも動くようにしておきました。

2)プログラム表示の変更

最終コーナの2つ目は老後の楽しみのプログラム表示の変更です。
というのも、現状のプログラムでは何の表示もないので、どんなプログラムが乗っているかぱっとみてわかりません。
まあ、忘れることもないと思うのですが、自身ありません(汗

ということで、ちょっとだけオープニングメッセージを派手にしました(笑


こんな感じです。これは完全な自己満足の世界です。

これで、ひとまず完成!



高速化! 2020.6.22
ソフトを見直して、ディスクアクセス関係の高速化をはかりました。とくにSDカードのアクセスについては
CCS−Cのライブラリを用いていますが、そこに使われているSPI制御の関数が汎用的であったため、
かなり機能を絞った形に修正しました。というのも、SPI関数は読み込みと書き込みが同時にできるようになっていますが、
実際のSDカードのアクセスは読み書きを同時にすることがないので、読み込み専用、書き込み専用を用意して
使うことにしました。
 これで、かなりに高速化がはかれました。半分までは行きませんでしたが半分近くまで高速化できるました。
勿論、RAMディスクには到底及びませんが、まあいい線いっていると思います。

本来はPICにはSPI用のハードウエアが搭載されているので、それをつかうのが一番高速だとは思うのですが、
それをすると接続するPINが限定されてしまうので、SPI通信についても、PICの任意の足に接続して、あとは
ソフトウエアで制御を行っています。

SDカード上
(改造前)
SDカード上
(改造後)
RAMドライブ上
コンパイル 57秒 33秒 3〜4秒
リンク 46秒 29秒 11秒
103秒 62秒 14〜15秒

CCコンパイラが貧弱!

CPM68Kを動かしたくなった1つの要因に、CPM68KにCコンパイラが内蔵されていることがあります。
ボードも動くようになったので、つかってみようとおもってプログラマーズガイドをみてみると、
かなり大きな制約があるようです。主要なところです。

・浮動小数点が使えない。
 使えないなら、コンパイルエラーでも出してくれればいいのですが、なんかコンパイルもリンクも通るのが
 恐ろしいです。

浮動小数点は使えません。コンパイル&リンクはできたりしますが
値は出鱈目です。表示もやる気なしです(笑)。

・変数や関数は8文字までしか識別しない
 これは結構、バグの原因になりそうです。間違った関数を呼んでいることに気づかないかもしれません。
 8文字に限定されているのはおそらくリンカーあたりが古い設計なためでしょう。
 C言語で可読性を上げるために、変数名等は長くしたいのですが・・・・・・

その他、自動変数の初期設定ができないとか、色々と制約やあります。
まあ、このCコンパイラはユーザでのアプリケーション開発を目的としたものではなく、
単純にBIOSとかを書くために、便宜上いれておいた程度のもののようです。
でも、ないよりマシかな。流石にアセンブラだけだときついです。


RAMを増設する!? 2020.6.24

いろいろCPM68Kを弄りだしていて、速度の点からRAMディスクは必須なのですがやはり1MBでは容量が少ないです。
C言語を動かすためには少なくとも500kBは必要なのですが、それ以外のコマンドファイルなどを入れだすとすぐに容量が満杯になってきます。
ということで、もうすこしRAMディスクを増やすべく増設を計りましょう。

増設の方法はいくつか考えられますが、

1)メモリーの交換・・・×
  より容量の大きいメモリーに交換するのが、手っ取り早い方法です。現在は4MB(512k×8bit)をつかっていますが、それを16MBなどへの変更です。
 色々の探してみると、16MBのSRAMはあるのですが、同じ32PinのDIPパッケージのものがありません。そりゃ、そうでしょうね。以前に探したときも、
 DIPパッケージで一番容量の大きなものを選んだ覚えがあります。それに32Pinで4MBというのはピン数の限界です。アドレス19、データ8、RD,.WR,CE
 そして電源2とあわせて32ピンです。
  

2)親亀、小亀方式で増設・・・◎?
 たぶん、これ一択かな〜と思っています。メモリーの接続ほCE端子以外は、ほとんどが共有なのでICを重ねるのがもっとも簡単な増設です。
 半田付けも一番すくないし・・・。ただ、見栄えはあまり宜しくありません。

3)単純増設・・・△?
 ボード上にはスペースがあるので、そこにあと2MB分は増設できます。そうすれば基板の高さも低いままだし見栄えもいいです。
 ただし、一番面倒なのがRAMの配線をすべてやらなければならないということです。
  でも、ポリウレタン被覆銅線をつかえば、まだ簡単に配線できそうだし、最近になって半田ごての温度を上げれば、被覆が早く溶けることがわかって
 きたので、もう一度チャンレンジしてみたい気もします。

 RAM増設のためのスペースはまだあります。配線が面倒か〜?

ここは3)案で
 目的(RAM増設)優先なら迷わず案2)ですが、ポリウレタン被覆銅線をなんとかつかってみたいという手段重視で案3)を選択です。
 さて、吉とでるか凶とでるが・・・・。

ワイヤリングペンを作ろう!
 ポリウレタン被覆銅線をつかうときにあると便利なのが、ワイヤリングペンらしいです。いままではピンセットでワイヤリングしていましたが、
色々とWEBをみていると、必須のような書き方をよくみかけます。ということで、一度つかってみようかと思っています。シャープペンシルが
あれば簡単につくれるようです。
 家の中でシャープペンシルを探しますが、意外とないものです。ボールペンなら山ほどあるのですが・・・それも、見本市でもらったものが(笑。
2本ほどみつけましたが、先がプラスチックのものばかりです。半田の熱が加わる場合もあるので金属製のほうがいいようです。

ということで寄り道して100均一で探してみることに。そうしたら、1本だけ先端が金属のものがみつかりました。


1種類だけ先端部が金属製のシャープペンシルがみつかりました。


ペン先が金属になっているので熱にも強いでしょう。

あとは、必要なものは針金とコイル巻きのボビンです。ボビンについては、ミシンの下糸をまくボビンを妻のミシンから失敬しました。
もちろん、空のスペアのものですよ〜。


こんな形でできました。



ボビンが空回りしないように中央にスポンジを入れています。

つくっていて色々と気づきました。

・ボビンにはかなりの銅線が巻けるので、ほどほどに。
 巻くときはドリルにボビンをつけて回転させますが、直径が太くなるには結構な時間がかかります。
 取り替えるのが面倒なので、できるだけ沢山巻きましたが、あまり沢山まくと、巻き解けて銅線が軸にからまります。
 巻く量は半分くらいがよさそうです。それに半分も巻けば一生つかえるだけあります。

・銅線をシャーペンの中を通すのが一苦労
 いろいろなところにひっかかります。胴体部を通すのも難しい・・・・・。そこで胴体部については竹串をガイドにして通しました。
 最難関は先端部分です。これは、ひたすらトライです・・・・。 先端からなら簡単に通るのですが・・・・。

・ボビンの空回り防止が必要。
 勝手に回ると、銅線が巻きほぐれてしまいます。それと、銅線が出て行くときの抵抗が小さいと、ピンに銅線をまきつけるのが
 難しいです。そのため、ボビンが勝手にくるくる回らないようにスポンジを詰め込みました。

快適!!
 いざ、このワイヤリングペンをつかって配線をしてみますが、快適です!
 いままでの、電線をつかった配線に戻れそうにありません。銅線を1ライン分を敷設して、最後にまとめて半田するだけで
 簡単に配線ができます。

 ただ、快適に作業するには、すこしコツがいりそうです。
・半田コテの温度は高めに。
 私の場合は420度設定です。コテをあててて、半田を流し込んで、しばらくコテをあてつづけていると、被覆がとけたときに
 一気に基板のパッドに半田が流れ込み、山形の半田形状になります。反対に、半田が綺麗に流れ込むまでコテを当て続ければ
 確実に付きます。

・ICソケットのピンは最初に半田付けしない。
 ワイヤリングペンでピンに1回あるいは2回程度、銅線をまきつけたほうが確実に取り付きます。そのため、ピンは半田付けしないほうがいいです。
 電源ピンのみ、ICソケットの固定として半田付けしておきます。

・ワイヤーはゆるゆるに配線
 ワイヤーはきつきつに張ったほうが綺麗ではあるのですが、半田コテが触れると被覆がとれてしまう可能性があります。
 ゆるゆるに配線しておけば、半田づけする位置の配線をピンセットでどかすことができませす。ピンとはってしまうと、
 溶けてほしくない被覆がとける場合があります。


結構配線数は多いですが、比較的短い時間でできました。

配線後はテスターで導通チェックをおこないましたが、問題なしでした。

制御線を配線する!
さて、RAMの増設のベースはできましたがRAMの制御回路を変更する必要があります。
もともとは2MB実装しか想定していませんでしたので、すこし制御回路も変更しなくてはいけません。
4MB限定にするなら簡単な変更で済みましたが、折角なので最大8MBまで制御回路をほとんど弄らずに
増設できるように変更しました。ただ、8MBのRAMを実装するには、もう基板のスペースがありませんから、
親亀小亀方式をとる必要があります。しかし、8MBまで増設するかな〜・・・といいつつ、SRAMは注文しちゃいました(笑。
 8MBあっても何につかうの?てな感じですが、まあ自己満足です。


改造前のメモリー部の制御回路です。メモリーの増設は考えていなかったようです。


改造後のメモリーの制御回路です。最大8MBまで増設することを意識しています。

まずはRAMの追加完了!

さて、全体のHWの改造は完了しました。
ついでといってはなんでしたが、SRAMのバッテリーバックアップ機能も追加しました。簡単に1Fのスーパキャパシタを載せています。
これは秋月の福袋にはいっていたものです。5個ぐらいはいっていました。
 1Fでどこまで保持できるかわかりませんが、あまり長時間の保持は狙っていません。すくなくとも、電源を供給しているUSBの差し替え
程度は保持してくれれば十分です。とはいいつつ2〜3日は保持できたら嬉しいな〜。これについては、電圧を監視してチェックする必要が
あるでしょう。


SRAMの増設が完了しました。ついでにスーパーキャパシタによるSRAMのバックアップも追加しました。

さて、引き続きRAMディスクの容量を増やすべくBIOSの修正です。これが、また面倒くさいです。

しかし、なかなかオーディオネタに戻れないな〜・・・orz

2MByte RAMディスク 実装完了!
BIOS、CPM.SYSならびにPICのシステムプログラムを変更して2MBのRAMディスクの実装が完了しました。
これで、まずはRAMディスク容量は気にすることはないでしょう。たぶん・・・。


RAMディスク(B)のドライブ容量が2MByteになりました。

バッテリバックアップの状況をみてみよう!

RAMドライブの容量が増えたのはいいけれど、その内容がバッテリーでどの程度保持できるか調べておきましょう。
ちなみにバッテリーであるスーパーキャパシタの供給すべき電流は下記の通りです。

 RAM スタンバイ時     4uA × 8 = 32uA
 ロジックIC 74AHC138  40uA × 2 =  80uA (-40 - +85deg)
-------------------------------------------
  計                        112uA


74AHC138の待機電流が読めないところで、+25℃に限定すれば4uA/個です。-40〜85℃での最大値が40uAなので
どれが実際の値かはよくわかりません。
あと気になるのはスーパキャパシターからSRAM以外のメイン回路への電流の流入防止ダイオードにショットキーを使いました。
これは逆電圧が小さいためなのですが、ショットキーは普通のダイオードに比べると漏れ電流が大きいです(そのため耐圧が低い)。
これもかなり悪さをするかもしれません。
 それにしても、最大値で112uAだとすると1Fのキャパシタでは1日とかは厳しいでしょう。電池を抱かせたほうが
いいかもしれません。
 一度、一晩放置してみましょう!


UARTの憂鬱? 2020.6.26

CPM68K(CPM80含む)とPCとの通信はRS232です。具体的にはCPM68Kのボード上のPICがRS232の通信を担っています。
RS232といっても、実際にはPCとの接続はUSBであり、基板上にUSB-RS232の変換用の素子を搭載していますので、
実質的にRS232での通信距離は数cmです。
 で、CPM80のときにはあまり気にならなかったのですが、CPM68Kではコマンドファイルが大きいのでディスク(SDカード)
からの読み込みに時間がかかります。たとえばBASICコンパイラは200kB近くあるので、読み込みは数秒かかります。
で、ディスクからの読み込み中にキーを入力すると、コンパイラが立ち上がって、そのままフリーズです。CPM80のときは、
読み込みファイルのサイズがあまり大きいこともないので、コマンドの実行までキー入力を待つことができましたが、
CPM68Kではつい先走って、キーをたたいてしまいます。
 システムがフリーズしたらどうするか?それは、リセットです。リセットボタンをポンと押せば、
まずはモニタープログラムが立ち上がり、そして”X"を押すとCPM68KのシステムをロードしてOSが起動します。この間の
時間は2〜3秒。時間も短いのでリセットへの抵抗はほとんどありません。
 でも、よく考えたらマイコンとはいえコンピュータがフリーズしたからといってリセットをかけるのは異常事態です。
WINDOWSのPCでリセット(電源再投入)しようものなら、数分立ち上がりを我慢しなければなりませんし、HDDの中身も
心配です。それを考えたらマイコンといえどもリセットを押すという事態は、できるだけ避けたほうがいいでしょう。

フリーズの原因は?
 最初はCPM側の問題と思っていました。というのも、昔のPCなのでもっとのんびりと作業をしないと糞詰まるのだろうな〜、
程度に考えていました。CPM68Kになってリセットを押す機会が増えてしまうと、たとえわずかな作業だとしても、システムの再起動が面倒に
なってきます。そこで原因を調べてみました。わかったのはPIC内にRS232をつかうためにUART機能があり、駆動ルーチンはCCSのライブラリ
をつかっていますが、そこに問題がありました。PC(キーボード)からRS232でデータをPICに送り、
PIC内のソフトでデータが来たことを確認したのちにデータを取り出すのですが、データを取り出す前に次のデータがPCから来てしまうと、
読み込みのバッファーがないためか、そこでエラーが発生するようです。そこで、システムがフリーズするのもおかしな話ではあるのですが、
データの読み出しにいったら、そのまま戻ってこないということになってしまうようです。

対策は?
 原因がわかれば、この対策は簡単です。要は、PICのUARTにデータを溜め込まないようにすれば言い訳なので、
UARTがデータを受信したら、割り込みをかけてデータを読み込んでリングバッファーに蓄えます。これだけです。
そして、データはUARTから直接読むのではなく、リングバッファーから取り出すようにします。
プログラムはいたって簡単。下記の割り込みルーチンをあらたに加えてます。そして、いままで読み出しで使っていた
次のサブルーチン
kbhit()  キーボードが打たれたかどうかを返すサブルーチン
getc(c) 1文字入力
を、それぞれkbhit2()、getc2()に置き換えるだけです。


リングバッファー処理の割り込みルーチンです。

これで、サイズの大きなコマンドファイルの読み込み中にキーをおしても、フリーズすることはなくなりました。
コマンドが立ち上がったときに、打ち溜めた内容が一気に表示されてくれます。

追加の効能?
 CPM68Kではラインエディターしかないので、WIN-PC上のエディタでファイルを作成してRS232経由でファイル内容を送信していますが、
取りこぼしが出ないように、通信速度を38400ボーまで落としているのですが、このリングバッファー機能を入れることで
通常の115200ボーで動かしてもとりこぼしがでないことをがわかりました。案外、こっちの効能のほうが嬉しかったりします。
改行などの制御コードが送られたときの処理速度が、全体の受信速度を律即していたようですが、それが緩和されたようです。


スーパキャパシターの持ちは?

電源を切ってから、1日分のスーパーキャパシタの電圧を測定してみました。結果は下図の通り。
SRAMの内容保持電圧限界は1.5Vなので、24時間程度は保持できそうです。

スーパーキャパシタの電圧変化。1日はSRAMの内容は持ちそうです。

で、このグラフの曲線から負荷をざっと計算すると、およそ100kΩ程度になります。
ということは、初期電圧5Vとすれば50uAの電流が流れることになります。
SRAMが4uA×8=32uA、ロジックIC(AHC138)が4uA×2=8uAですから、約40uAですからほぼカタログ値どおりですね。
ただし、これから夏場にはいると電流が多くなるので短くなりそうです。

しかし、1日保持できるというのは中途半端だなあ〜。瞬停に対しては十分ですが、
しばらくの出張には耐えられません。やっぱり、ボタン電池搭載するかな? たとえばCR2032だと
公称容量220mAあるので、40uAとすれば5500h、すなわち約230日は持ちそうです。


CR2032の仕様です。これはMAXELLの製品の場合。


(続く?それともPART2になる?) → 次男が誕生しました! 2020.6.27