TRY！ CPM-68Kの巻き 2020.5.31
（CP/M-80をつくるぞ！からの後半戦です）
まずは資料の収集です。CPM68Kに関連しそうなものを集めました。
まず、マニュアル類の中でシステムガイドが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～２０MB程度です。それ以上あっても、使いきれません。
結果は、SDカードでもなく、SDHCカードでもないという返り値が戻ってきました。
やっぱり、真性の不良品だあ～！！！ ちょっと出鼻をくじかれました。
SDあるいはSDHCカードから調達に入らないといけなくなりました。
やっぱりつかえなかったSDカードです。 お気楽雑記帳2019（No.59)
まずは68KとPICとの通信から 2020.6.1
MC6800でのBIOSの処理のほとんどはPICに任せますが、そのやり取りを決める必要があります。
パラメータの受け渡しはSRAMを経由して行いますが、その処理の流れは別途２本の通信線で行うこととします。
MC68000とPICとの信号の流れです。
手順としては
①MC68000側はパラメータをSRAMに書き込んだ後に、PICにBIOS処理リクエストを送信
②PICはリクエストを受け取った処理を行い、SRAMに返答用のパラメータを書き込み。
そして処理済み応答を返す。
③MC68000はPICからの処理済み応答があったことを確認して、処理リクエストを解除。
④PIC側はリクエスト解除を確認したら、処理済み応答を解除
これが一連の流れになります。
信号受け渡しの手順です。
この一連の流れを一応、簡単なプログラムを書いて確認です。
ほとんど処理のない状態で、この一連のサイクルはだいだい13kHzの周期になるようです。
実際の処理の状況をモニターしていると、MC68000での応答了解（リクエスト解除）があってから、
PICによるリクエスト解除確認はほとんど瞬時なので、それをMC68000側で確認する必要はなさそうです。
その部分の処理を省けば少しでもサイクルタイムは短くできそうですが、全体が動いてからにしましょう。
手順どおりに動いていますね。
わからない？？？
CPM68Kの最初のシステムはCPM15000.SRとCPM400.SRがありますが、どっちをつかうのがいいのだろう？
この数字の部分はCPMのDOSが開始するアドレスで、それぞれが$15000と$400を示しています。
CPM80のDOSはメモリーの一番後ろにあって、０番地からDOSまでの空間が使用できるメモリーとなるので、
条件的にCPM15000.SRを使おうと思っていました。そうすればメモリーの最初から＄15000番地（約80kB)は使えることになります。
それに対してCPM400.SRの400って1kBのポジションですから、活用できるメモリーがないじゃないですか！
ひょっとして、ユーザがつかうメモリーの位置ってDOSの前でも後ろでもどちらでもいいのかな？それなら、CPM400.SRを使って
DOCをできるだけメモリーの最初の方に配置しておけば、それ以降のメモリーは自由に使えるわけですからCPM15000.SRより
使いかってはいいはずです。そう考えると、CPM15000.SRを用意する意味って何があるんだろう？？？？
いまのところ謎です。
とかまあ、こんなこと言っているレベルなので、本当にCPM68Kが動くところまでいくかどうか、かなり心配になってきました。
次のマイルストーン 2020.6.2
とりあえず次のマイルストーンを設定しておきまししょう。まずは、速度・容量は完全に無視してプロンプト A> がでるところまで
をめがけていきたいと思います。そのためには下記をすすめていきましょう。
１）BIOS（PIC側）の作成（C言語）
とりあえず、ディスクアクセスの速度は考えない（SDカードの読み書きは512BYTE単位で、CPMの読み出し単位は128BYTEなので、
うまく扱えば、読み書きの速度があがりますが、当面考えない）。
２）MC68000側のBIOSの作成（アセンブラ）
BIOSのサンプルが使えるように、ディスクの容量は８インチで片面単密度（２４０ｋB程度）で設定。
３）CPMディスクをSDカードに書き込み
とりあえずDDT（デバッガ）あたりが動けばいいでしょう。
４）システムのロードは通信
ＳＤカードにシステムをいれて、それをロードするのもまずはハードルがあるので、とりあえずＳフォーマットレベルでＳＲＡＭに書き込む。
※最終的には、ＰＩＣの容量に余裕があればシステム（ＤＯＳ）は、ＰＩＣに内蔵しておいて直接ＲＡＭにダウンロードするようにすれば、
高速に起動できるでしょう。
動かない・・・
１）～４）を準備して、いよいよ起動です。PICでのモニタープログラムから、制御のMC68Kに移しますが、見事に動きません。
原因を探るべく、BIOSコールがかかればPICに制御が移るので、そこで引き渡されるパラメータ(データレジスターD0～D2)を
確認しますが,最初はD0=0（COLD BOOT）、次はD0=1（WARM BOOT)、そのあとは無茶苦茶な数字です。
最初にCOLD BOOTがBIOSでCALLされるのも変なのですが、ひょっとして動いているのだろうか？WARM BOOTがかかったら
CCPに制御が移るのだけど、それ以降がおかしいのかな？？わからないな・・・・・。
なにか根本的に間違えているのかもしれません。いや、根本的に知識が不足してるのかも（汗
ここで、この企画もおしまいになってしまうのかな～とちょっとモチベーションダウンです。
悪戦苦闘・・・
１．コードを追跡すべく、CPM68Kのシステムをすべて逆アセンブルしてコードを一から追跡します。でも、すぐに断念。
だって、なにやってるかわからないし、それにいつになったら原因が判明するか・・・わかりそうにありません。
２．フリーのMC68Kのシミュレータをインストール。でもその使い方がよくわからない・・・・・
３．BIOSコール毎にCPUをリセットして、レジスターの値をチェック・・・・ん？おかしい？
PICで認識するBIOSの機能NOと、MC68K側で送り出している機能Noが一致しません。これが原因か？
原因判明！
簡単なバグでした。レジスターD0の値はメモリーを経由して引渡しますが、MC68Kでメモリーに書くときはLONG（32ビット）にしています。
BIOSコールを受けてPICで読み出すときも陶然LONGで読み出したつもりが、WORD（16ビット）での読み出しになっていました。
変数のビット数が異なるので、当然メモリーに格納される位置がずれていますから正常な値が引き渡されていなかったようです。
ということでPIC側のCプログラムを修正です。
今度は動くかな？
動いた？？？あれ？
さて、PIC側プログラムを修正して再度起動に挑戦です。
ををを！ プロンプト A> がでました。こりゃ、動いていそうです。でも、エラーも同時にでています。
なにやら、例外処理の＃３でユーザアドレスがなんとかかんとか・・・なんのことやら。
どうやらファイル名の一覧（DIR)もできないことから、ディスク関連のルーチンにバグが残っているのかもしれません。
でも、かなり前進です。
なにかエラーが発生しています（例外処理の＃３でのユーザアドレスの違反？なんのこっちゃ）。
ちょっとやる気がでてきました。でも、遅いので早く寝よ！
デバッグは続くよ、どこまでも・・・・
エラーの原因を確認すべく、BIOSコールがかかった位置を特定していきます。
コンソールの入出力関係以外でBIOSコールがかかったら、システムを一時停止させます。
さて、何が原因かな？
エラーの出る直前の呼び出しはDISK SELECTでした。
調べてみたら、パラメータの引渡しを間違えていました。とりあえず修正です。
エラーの直前はNO.9のBIOS機能呼び出しです。ここが怪しい・・・。
とりあえず修正して走らせてみました。今度はエラーはでません。
おそるおそる DIR と入力すると、ファイル名がでてきました。
多すぎる！
たしか、ディスク（SDカードをつかっている）には２個程度のファイルしか入れていないのですが、
なんども同じファイル名が表示されています。まだまだ、バグがありそうです。
ただコマンドとして
A>DDT680000
と、叩き込んだらフリーズしてしまいました。
でも、一歩前進かな～！！
修正したら、ディレクリがでるように？？？？あれ、数が多すぎる。同じ名前がいっぱいあります。
今回のBIOSで、すこしややこしいのがBIOSからの戻り値をMC68Kに搭載したBIOS側で
行うのか、それとも一旦外部処理にまわすPIC側で行うかの混在があります。これも
間違いの要因でもあったので、すこし備忘録代りに整理しておいたほうが良さそうです。
BIOSとPICプログラムの再度見直し！
上記の表にもとづいて、BIOSを一旦整理です。どこか間違えている？ということはわかりませんが、とりあえず動かしてみましょう。
ん・・・・システムがフリーズすることはなくなりましたが、なんかエラーがでるな～。
おそらく、ディスクのディレクトリが正しく読めてないことからファイルサイズがおかしくなっているのでしょう。
エラーは出ていますが、システムがフリーズすることはなくなりました。
次はなにをチェックしたらいいだろう？とりあえずディスクシステムをもう一度作りなおしてみるのと、
ディスクのREAD/WRITEのCプログラムをチェックしてみましょう。
さらにデバッグ・・・迷宮にはいりつつ？？？？
色々と試しているが、だんだん症状が悪化しつつあるような・・・。
かたっばしから、状態を表示するようにしてみると不可解な現象が発生します。
①頻繁に初期化が走る。CTRL-Cを押せば、普通はWARM BOOTのはずだが、なぜかCOLD BOOTになってします。
②表示の途中でなぜか、キーの入力待ちが発生してします。
③いきなりドライブＪを選択しようとする。
実は③については、ドライブ選択の機能ＮＯが９なのと、ドライブ番号９がＪなので、ひょっとして単純なミスだとおもわれるのですが、
何回ソースを見かえしても間違いはないようなのですが・・・・・
ちょっと頭を休めたほうがいいかな？
ああ、また半田ゴテで遊ぼうかな！と現実逃避、敵前逃亡です（笑。
一難去って、また一難！ 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も印刷して、眺めていますがよくわかりません。
画面で見るとしんどいので、紙に印刷したら１２０枚もありました。
そろそろプリンタトナーが切れてくるころだなあ～。
まあ、それはさておき、今後のデバッグに役立つかもしれないので、おかしな現象をピックアップです。
おかしな現象１
・テキストファイルをTYPEすると普通に表示される。 （これはOK）
・実行形式のファイルをTYPEするとエラーが発生する。 （これもOKなのかな？）
・次に、テキストファイルをTYPEするとエラーがでる。（これはおかしいのでは？）
その他のDIRやERAなどのコマンドは問題なく実行できる。
一度エラーがでると、次からTYPEができない。
おかしな現象２
実行形式のファイルについては、そのヘッダ部分が決められています。
ED．RELの場合のバイナリーをみてみると、下記のようになっています。
ＥＤ．ＲＥＬのプログラムヘッダ。１６Ｈから始まるパラメータは０Ｈになっています。
気になるのが16Hからはじめる"テキストセグメントとプログラム実行の開始”が０Hになっていることです。
サンプルでは５００Hになっていて、あたかもプログラムの開始アドレスになっていますが、MC68000で開始アドレスが
０Hというのはおかしいのだけど（0H～４００Hまでは例外処理ベクタが割り当てられている）、これでいいのかな～？
たとえば、これを弄ったらうごくのかな。しかし、いちいちこれを弄るなんて、書いてないしなあ～。
なんかプログラムで一括して変更できるようになっているのだろうか？謎だ～。
他のプログラムをみては大体、０ＨだけどＳＴＡＴ．ＲＥＬは１０００Ｈだったけど、これなら動くのかな？
でも同じくＰＩＰ．ＲＥＬも１０００Ｈだけど動かなかったなあ～。
ＳＴＡＴ．ＲＥＬのプログラムヘッダ。こちらは１６Ｈから始まるパラメータは１０００Ｈです。
だんだん敗戦色が濃くなってきました・・・・・。
あとは、何ができるかな～？？？
微速前進・・・・・
CPM80の三兄弟ができあがったこともあるので、再度このCPM68Kの見直しです。じつは、CPM80のデバッグにおいて、
重要な情報がえられたかもしれません。というのも、CPM80でテキストの表示はできるのだけれど、コマンドファイルの実行ができない
バグにぶちあたりました。このときの、バグの原因はティスクの読み書きのｻブルーチンに問題がありました。その状態でも、
ディレクトリの表示は問題なかったこともあるので、このCPM68Kとかなり類似した症状です。ということで、まずは
ディスク周りを徹底的に見直すことにしました。
１）まずは、ディスク内容そのものが正常かどうか？
CPMのディスクを作るにはCPMTOOLSというソフトを使っていますが、それをつかって作成されたファイルが正しいかどうかのチェックです。
１つのコマンドファイルをディスクに書き込んで、再度読み出して同じ内容になっているかを確認です。これについては問題ありませんでした。
まあ、ここで問題があるようだと、テキストファイルも正常に読めないでしょう。
２）ディスクの読み書きサブルーチンは大丈夫か？
これも、何度も見直しました。が、問題はなさそうです。これも長いテキストファイルが正常に読めることを考えると、とくにバグはないでしょう。
それより、バグのリスクを減らすために、ブロッキング・デブロッキングの処理は一切省いています。そのため、ディスクの読み書きの速度は
かなり遅いです（そのかわりバグのリスクは少ない）。
どうやらディスク周りはでなさそう・・・・
こうなったら！
アセンブラのソースを一行づつ、丁寧に見ていきましょう（もう何度もやった気がするけど・・・・。
あ！！！
BIOSアセンブラを眺めていて、１箇所間違いをみつけました。BIOSコールのときの処理番号はWORD(16Bit)でパラメータが引き渡されますが、
それをLONG（32Bit)で処理しているところがありました。WORDで処理するなら上位16BItは無視されますが、LONGだと上位16Bitも関係してきます。
そこで、予め上位16Bitをマスク処理しておくことにしました。そして、再度アセンブルして実行です。
微速前進！！
TYPEコマンドでテキスト表示をさせるときに、２回目の表示をさせようとするとシステムがフリーズする現象がありましたが、このバグの修正で
直りました。何回TYPEコマンドを実行しても、フリーズすることはなくなりました。
でも、あいかわらずコマンドファイルの実行はできません。相変わらず
[Insufficient memory or bad file header]
なる、エラーがでてきます。でも、すこし前進しました。ほんの微速ですが・・・・・
動いた？
こうなったら、面倒ですがBIOSがコールされる前に、引き渡されたパラメータと処理して引き渡すパラメータをすべて表示させてチェックです。
すべてのBIOSコールをやると、画面が無茶苦茶になるのでコンソールの入出力以外での表示に限定します。
で、最初の方にでてきた「GET ADDRESS OF MEMORY REGION TABLE」と呼ばれるBIOSコールの戻り値がおかしいことを発見です。
本来はテーブルが格納されているアドレスである「０ｘ１ｂｂ２０」が返されるはずですが、そのままBIOSのコール番号「１８」が返っています。
どうやら、戻り値を間違えてオーバライトしている行があることに気づきました。ひょっとしてこれが原因だったのかな？メモリー範囲を示す
テーブルが間違っていたらから、[Insufficient memory or bad file header]というエラーが発生していたことと辻褄があいます。
で、早速修正して実行です！
動いた！！！！
PIPコマンドが実行できました。
ををを！いままでエラーが出続けていた、コマンドファイルの実行ができるようになりました！！！
これは嬉しい！
おおきな前進です。
かなりやる気がでてきました。 でも、夜も遅いのでここまでにしておきましょう（きりがない・・・。
次なるマイルストーン 2020.6.19
つぎのマイルストーンの設定です。いまは標準のディスク構成（８インチ片面単密の240kB)なので、全然容量がたりません。
なんせCPM68Kは標準のディスクで９枚ものボリュームになります。
まずは、ディスク容量を増やすことも必要なのですが、現時点で動くプログラムにはバグチェックのための不要なルーチンがいたるところに
入っています。そこで、次なるマイルストーンは
・一旦すべてのプログラムを綺麗に（短く）整理
・ディスクの容量を拡大（１ディスクあたり２MBくらいで８ドライブで十分かな？）
まずは、ここまで進めましょう！その前に、いま仮にでも動いているプログラムを上書き修正すると、取り返しつかないことになりかねないので、
バックアップをとっておかなくっちゃ！
まずは一段落？
とりあえず、プログラムの中から不要なものは排除してスッキリさせました。
あと、ディスクは８MBを４ドライブ分設けました。
これでCPM68Kのすべてのシステムファイルを１つのドライブに余裕をもって入れることができました。
１ドライブですべてのファイルが収まりました。
まだまだ腑に落ちません
いままで動かなかったコマンドファイルも問題なく動くようになりました。
一応、動くようになったと思うのだけど、わからないことが多々あります。
実行ファイルには拡張子が．６８Ｋと．ＲＥＬがあって、前者が絶対アドレス配置のもの、．ＲＥＬが
どこにでもおけるものらしい（リロケータブル）。それはいいとして、実行するためのファイルのタイピングは、
拡張子が６８Ｋのものは、ファイル名だけでよいが、ＲＥＬの拡張子のものはファイル名と拡張子を両方いれないと
いけません。でも、ほとんどのコマンドファイルの拡張子はＲＥＬになっています。
で、マニュアル見ると、コマンドファイルの実行はファイル名だけを入れるように指示されています。
ということは、ほとんどすべてのファイルは68Ｋの拡張子になっていないと駄目ということです。
ひょっとしてＲＥＬを68Ｋに変換するコマンドがあるのだろうか？ひょっとしてこの作業は手作業？
まさかそんなことはないよね～？？？
とりあえず動くようになったのは前進なんだけど、まだまだ大切なことを見逃しているようです。
まだまだ調べなくては・・・・・
ちょっと使ってみる！ 2020.6.20
だんだんわかってきました
実行ファイルで拡張子のＲＥＬと68Ｋの違いは、前者がリロケータブル（どこでも配置可能）に対して、
６８Ｋが絶対番地指定なのだが、それだったらＲＥＬだけでいいやん！と思っていたが、どうやら
実行速度とディスク容量が大きくちがうと書いてあった。
実際に比べてみると、ＲＥＬに比べて68Ｋの方が半分くらいの容量である。ということは実行にかかる
時間（ディスクの読み込み）も半分になるということなのですね。なるほど。
容量がＲＥＬと68Ｋでは倍半分と違います。CO６８はＣのコンパイラの一部です。
ということで、メーカからの配布版についてはＲＥＬとしておいて、ユーザ側でのメモリー配置は個別に
違うので、それらにあわせて68Ｋファイルに変換してください、ということのなのでしょう。しかし、
ＲＥＬファイルって結構な数あるので、１個１個ほんとうに処理するのかな？
ちなみにＲＥＬから68Ｋファイルに変換するには ＲＥＬＯＣ．ＲＥＬというコマンドファイルを使います。
そのため、
A>RELOC.REL AS68.REL AS68.68K
といった作業を延々と繰り返す必要があります。途中面倒になってＳＵＢＭＩＴファイルを書いたりしますが、
またエディターがラインエディター（ＥＤ）しかなくて、これがまた使いにく・・・というか全然使い方がわかりません。
せめてＷＭ（ワードマスター）くらいのスクリーンエディターがないの？と思ってしまいます。
で、なぜこの作業が必要かというと、Ｃコンパイラを使おうとしたときに、すべて68Ｋファイルにしておかないと
ＳＵＢＭＩＴファイルが文句を言ってきます。なんせ、ＲＥＬファイルで動くようには記述されていません。
ほんとに、CPM68Kをうごかしておられた人は、こんな面倒なこと（RELから68Kへ変換）をしたのでしょうか？
やはり謎だなあ～。
とりあえず、
CPM68Kも動かしてみるということで、C言語で簡単なプログラムを書いて実行してみましょう！
これは、お約束のようなプログラムです。
これをコンパイル＆実行してみましょう。
コンパイルとリンクを続けて行いますが、それにしてもパス数の多いこと！
リンクも含めて５パスです。たしか、このCは昔憧れのWHITE SMITHのCだったとおもったけど違うかな？
それにしても、わずかなプログラムですが、コンパイル＆リンクになんと１分５０秒かかりました。
おそらくSDカードのアクセスが遅いためでしょうが、これをフロッピーディスクでやったら、カップラーメンが
余裕でできそうです。
無事実行できましたが・・・・・遅すぎ！！！
もうちょっと、コンパイルが早いものがなければちょっと使うのはきついかも・・・です。
まあ、もともと動かすことが目的なので、これで何かをしようとはあまり思いませんが・・・・。
実用性を考えたらCPM80の方がいいかもです。処理速度はまけるでしょうが、コンパイル＆リンクも結構早いので
プログラム開発には向いているでしょう。
でも、CPM68KもRAMディスクを使ったら超速になるかも。あと、２MBほどメモリをたせば、世界が変わるかも
しれません。 まさか、やる？やれば？←悪魔の囁きです（笑。
あ！備忘録です。
Cコンパイラを動かす前に、アセンブラのAS68については初期化をしておく必要があります。
最初は、わけのわからないエラーがでて悩みましたが、マニュアルをみるとエラーの対処方法としての
初期化が書いてありました。
A>AS68.REL -I AS68INIT
で初期化をおこなうようです。
しかし、情報が少ない！
CPM68Kを動かすにも、色々なHPを参考にすればいいかと簡単に思っていましたが、実際に検索しても
ほとんどありません。あったのはここくらい。→ https://piclabo.blog.ss-blog.jp/2018-07-22
Z80のCPM80だと、ちらほらあるのですが・・・・
まあ、CPM80は８ビットのOSとして一世を風靡した感もあり、色々なソフトも充実していますから、
懐かしんで動かす人も一定の人がいそうです。それに対してCPM68Kはほとんど国内でも出なかったん
だろうな～と想像します。当時は他にCPM86やMS-DOSもあったし・・・・。それに68000が動くPCも少なかったしな～。
まずは、念願叶う！
こんかいのCPM68Kを作った目的は、まずはそれを動かすことですが、なかでもCコンパイラを実際に動かすことが
一つのゴールでしたの、念願が叶いました。
ここいらで、一旦お開きかな～と思っていましたが、つい最近にALIに頼んでいたMC680000が届きました。
64PのDIPなのでかなり大きいです。これを目の前にすると・・・・また、半田ごてを握りたくなってしまいます（笑。
直近でMC68000の16MHz版を入手しました。ああ～どうしよう。
さて、あとは最終コーナです
短いコーナだといいですが・・・。
最終コーナに入る前に・・・ 2020.6.21
RAMドライブを組み込んでみる！
Cプログラミングでコンパイルとリンクで２分弱（それも最短で）というのは、なんぼなんでもかかりすぎです。
今回の目的がCPM68Kを動かすことではありますが、これでいいの？という感じがフツフツと沸いてきて、
やっぱりRAMドライブを検討してみることにしました。
速度重視ですから、PICの制御は介せず、68000のBIOS内にサブルーチンを組み込むわけですが、
面倒かな～と思っていたら68000には便利なアドレッシングがあることがわかりました。それが、これです。
MOVE．L （A0)+、（A1）＋
この例ではA0アドレスの内容をA1アドレスの内容に移動し、その後にA0、A1レジスタの値をインクリメントします。
そして、ロングワードでの移動を指定してやればA0,A1は自動的に＋４となります。この命令を使えば、
簡単にメモリーの内容を移動できます。CPMでは１セクターのデータ数は１２８なので、この命令をロングワード
で扱えば３２回繰り返すだけでいいはずです。
で、横着して３２回のループを回すかわりにに、３２個の命令を並べることにしました。これが、一番簡単！
プロからみたら「汚いプログラム！」っていわれそうですが、ミスも少なくなるし、それに高速です（笑。
データの移動は、ループを省略して同じ命令を32個並べました。回数を間違えないようにコメントに回数を入れています。 |
ちなみに、この１つのMOVE命令は２０クロック必要です。１回の命令で４バイトの転送ですから、12MHzで動いている現在の
システムでの転送速度は、2.4MB/sになります。往年のCPUだからこんなもんかな？
さて、現状のRAMは全体で２MBありますが、このうち１MBをRAMディスクに割り当てることにしました。
１MBは切のいい数字で、１２８セクター×６４トラック×１２８バイト／セクター＝１MB なので、アドレスの計算もビットシフトだけで
できます。そのためプログラムは意外と簡単にできました。下手にセクター数を２０とか３０とかにしたら、掛け算が必要になるので、
間違える要因です。
組込み完了！
BIOSを修正して、BドライブをRAMドライブに置き換えました。
STATコマンドで、１MBの容量が確保できていることを確認です。
まずはBドライブをRAMドライブにしました。
爆速？！
さっそく、Cコンパイラを走らせてみました。必要なファイル類をすべてRAMディスクにコピーします。
１MBあったRAMドライブの残り容量は約５００ｋBです。これだけあれば、結構なプログラムがかけるでしょう。
メインメモリは１MBに減ってしまいましたが、いまのところはこれで十分な処理はできるでしょう。
で、肝心のコンパイルとリンクの実行速度は下記の通りです。もう、感激です。コンパイルのソース
内容は単純に「HELLO WORLD」をプリントする一行だけのものです。
|
SDカード上 |
RAMドライブ上 |
| コンパイル |
５７秒 |
３～４秒 |
| リンク |
４６秒 |
１１秒 |
| 計 |
１０３秒 |
１４～１５秒 |
とくに嬉しいのがコンパイル時間が1/10以下に短くなっていることです。バグだしはここで行いますから、
何度も実行します。ここでの時間短縮はプログラム作成の効果があります。反面、リンクは1/4程度にしか短くなっていません。
ここはコンパイルが成功してから通すので、少々時間がかかっても許せます。リンクにRAMディスクの効果が
低いということは、CPUががんばって動いているということなんでしょう。
それにしてもRAMドライブにすると、各コマンドファイルの反応がものすごくいいので、ストレスがなくなります。
いままではコマンドファイルの読み込みに数秒かかるので、１テンポ遅れる感じがイライラの元でした。
しかし、まあ～、これをフロッピーでつかっていた時代もあったわけですから、当時の人はストレスに強かったのでしょうね～。
（私も含めて）現代人はストレス耐性が弱いのかもです（笑。
さて、この感激を味わってしまうと、もう元には戻れないな～。やっぱりRAMディスクのために、さらにSRAM増設しようかな～。
やっぱりあったんだ！
RAMドライブをつかって色々なファイルをコピーしているときに、一連のSUBMITファイルがあることに気づきました。
中身をみると、RELファイルから68Kファイルに変換するためのコマンドが並んでいます。やっぱり、１個づつ人手で
やる必要はなく、まとめてできるようになっていたんだ！！！
全然マニュアルとかにも書いてないし・・・まあ、この手のものは書く必要がないのかもしれませんが・・・・
もっと便利なものがないか探してみよ～
RELから68Kに変換する一連のSUBMITファイルが用意されていました。
ようやく最終コーナに入れるかな？
最終コーナへ！
さて、いよいよ最終コーナーです。
１）システムの再構築
なにをするかといえば、システムの再構築です。というの、
今のメインメモリーは1MBで使用（残りの１MBはRAMドライブへ）していますが、CPM68KのOS（CCP+BDOS）は
SR15000をそのままつかっているため、メモリーの真ん中に居座っています。
メインメモリー ： ＄０００００ ～ ＄０ＦＦＦＦＦ
ＯＳ ： ＄０１５０００ ～ ＄０１ＦＦＦＦ
使用可能エリア ： ＄０２００００ ～ ＄０ＦＦＦＦＦ （約９１８ｋＢ）
そのため、すこし使えるメモリーエリアが無駄になっています。そこで、システムガイドに従って、ＯＳの位置を
メモリーの後ろ側においやって、使えるメモリーの領域を拡大してやります。
最終的には
メインメモリー ： ＄０００００ ～ ＄０ＦＦＦＦＦ
ＯＳ ： ＄０Ｆ８０００ ～ ＄０ＦＦＦＦＦ
使用可能エリア ： ＄０００４００ ～ ＄０ＥＦＦＦＦ （約982ｋＢ）
の形に変更します。もっとつめれば、さらに拡大できますがＯＳの配置はメモリーの切りのいい番地にしています。
まあ、単に境界の計算が面倒だったというだけです（笑。
手順は以下の通りです。
１）CPM68Kのアセンブラ（ＡＳ６８）でBIOSをアセンブルし、オブジェクトを作成する。
２）リンカー（ＬＯ68）でＣＰＭＬＩＢとリンクしてリローケータブルなＣＰＭ．ＲＥＬを作成する。
３）SIZE68でＣＰＭ．ＲＥＬのサイズを確認する。大体$6600くらいになります。
４）RELOCでメモリー配置を絶対番地の＄F8000にしたCPM.SYSを作成する。
本来は再配置を行ったＯＳ（CPM.SYS）は、ディスク（SDカード上）に配置しておいて、立ち上げ時に
それを読み出してメモリーにロードする形でOSを立ち上げます。しかし、ここでは変則的にCPM.SYSの中身を取り出して
PICのROMの中に格納しておいて、直接メモリーに書き込む方法をとります。この方法はメリット・デメリットがあります。
メリット
・とにかく起動が早い。
・SDカードが壊れていても、とりあえずCPM68Kが立ち上がる（これが重要）。
・ブートローダ用のＢＩＯＳを作らなくてもよい（これも重要）。
デメリット
・作成がちょっと面倒。
１）まずCPM．ＳＹＳをダンプコマンドでテキストエディターで編集できるようにする。
２）テキスト編集して、Ｃ用のデータファイルに書き換える。
・ＢＩＯＳの変更のたびにＰＩＣを書き換えないといけない。
まあ、BIOSを書き換えることもあまりないでしょうし、それに数年後に思い出したときにでも動くようにしておきました。
２）プログラム表示の変更
最終コーナの2つ目は老後の楽しみのプログラム表示の変更です。
というのも、現状のプログラムでは何の表示もないので、どんなプログラムが乗っているかぱっとみてわかりません。
まあ、忘れることもないと思うのですが、自身ありません（汗
ということで、ちょっとだけオープニングメッセージを派手にしました（笑
こんな感じです。これは完全な自己満足の世界です。
これで、ひとまず完成！
高速化！ 2020.6.22
ソフトを見直して、ディスクアクセス関係の高速化をはかりました。とくにSDカードのアクセスについては
CCS－Cのライブラリを用いていますが、そこに使われているSPI制御の関数が汎用的であったため、
かなり機能を絞った形に修正しました。というのも、SPI関数は読み込みと書き込みが同時にできるようになっていますが、
実際のSDカードのアクセスは読み書きを同時にすることがないので、読み込み専用、書き込み専用を用意して
使うことにしました。
これで、かなりに高速化がはかれました。半分までは行きませんでしたが半分近くまで高速化できるました。
勿論、RAMディスクには到底及びませんが、まあいい線いっていると思います。
本来はPICにはSPI用のハードウエアが搭載されているので、それをつかうのが一番高速だとは思うのですが、
それをすると接続するPINが限定されてしまうので、SPI通信についても、PICの任意の足に接続して、あとは
ソフトウエアで制御を行っています。
|
SDカード上
（改造前） |
SDカード上
（改造後） |
RAMドライブ上 |
| コンパイル |
５７秒 |
３３秒 |
３～４秒 |
| リンク |
４６秒 |
２９秒 |
１１秒 |
| 計 |
１０３秒 |
６２秒 |
１４～１５秒 |
CCコンパイラが貧弱！
CPM68Kを動かしたくなった１つの要因に、CPM68KにCコンパイラが内蔵されていることがあります。
ボードも動くようになったので、つかってみようとおもってプログラマーズガイドをみてみると、
かなり大きな制約があるようです。主要なところです。
・浮動小数点が使えない。
使えないなら、コンパイルエラーでも出してくれればいいのですが、なんかコンパイルもリンクも通るのが
恐ろしいです。
浮動小数点は使えません。コンパイル＆リンクはできたりしますが
値は出鱈目です。表示もやる気なしです（笑）。
・変数や関数は８文字までしか識別しない。
これは結構、バグの原因になりそうです。間違った関数を呼んでいることに気づかないかもしれません。
８文字に限定されているのはおそらくリンカーあたりが古い設計なためでしょう。
C言語で可読性を上げるために、変数名等は長くしたいのですが・・・・・・
その他、自動変数の初期設定ができないとか、色々と制約やあります。
まあ、このCコンパイラはユーザでのアプリケーション開発を目的としたものではなく、
単純にBIOSとかを書くために、便宜上いれておいた程度のもののようです。
でも、ないよりマシかな。流石にアセンブラだけだときついです。
RAMを増設する！？ 2020.6.24
いろいろCPM68Kを弄りだしていて、速度の点からRAMディスクは必須なのですがやはり１MBでは容量が少ないです。
C言語を動かすためには少なくとも500kBは必要なのですが、それ以外のコマンドファイルなどを入れだすとすぐに容量が満杯になってきます。
ということで、もうすこしRAMディスクを増やすべく増設を計りましょう。
増設の方法はいくつか考えられますが、
１）メモリーの交換・・・×
より容量の大きいメモリーに交換するのが、手っ取り早い方法です。現在は４MB（512k×8bit)をつかっていますが、それを16MBなどへの変更です。
色々の探してみると、１６MBのSRAMはあるのですが、同じ32PinのDIPパッケージのものがありません。そりゃ、そうでしょうね。以前に探したときも、
DIPパッケージで一番容量の大きなものを選んだ覚えがあります。それに32Pinで４MBというのはピン数の限界です。アドレス１９、データ８、RD,.WR,CE
そして電源2とあわせて３２ピンです。
２）親亀、小亀方式で増設・・・◎？
たぶん、これ一択かな～と思っています。メモリーの接続ほCE端子以外は、ほとんどが共有なのでICを重ねるのがもっとも簡単な増設です。
半田付けも一番すくないし・・・。ただ、見栄えはあまり宜しくありません。
３）単純増設・・・△？
ボード上にはスペースがあるので、そこにあと２MB分は増設できます。そうすれば基板の高さも低いままだし見栄えもいいです。
ただし、一番面倒なのがRAMの配線をすべてやらなければならないということです。
でも、ポリウレタン被覆銅線をつかえば、まだ簡単に配線できそうだし、最近になって半田ごての温度を上げれば、被覆が早く溶けることがわかって
きたので、もう一度チャンレンジしてみたい気もします。
RAM増設のためのスペースはまだあります。配線が面倒か～？
ここは３）案で
目的（RAM増設）優先なら迷わず案２）ですが、ポリウレタン被覆銅線をなんとかつかってみたいという手段重視で案３）を選択です。
さて、吉とでるか凶とでるが・・・・。
ワイヤリングペンを作ろう！
ポリウレタン被覆銅線をつかうときにあると便利なのが、ワイヤリングペンらしいです。いままではピンセットでワイヤリングしていましたが、
色々とWEBをみていると、必須のような書き方をよくみかけます。ということで、一度つかってみようかと思っています。シャープペンシルが
あれば簡単につくれるようです。
家の中でシャープペンシルを探しますが、意外とないものです。ボールペンなら山ほどあるのですが・・・それも、見本市でもらったものが(笑。
２本ほどみつけましたが、先がプラスチックのものばかりです。半田の熱が加わる場合もあるので金属製のほうがいいようです。
ということで寄り道して１００均一で探してみることに。そうしたら、１本だけ先端が金属のものがみつかりました。
１種類だけ先端部が金属製のシャープペンシルがみつかりました。
ペン先が金属になっているので熱にも強いでしょう。
あとは、必要なものは針金とコイル巻きのボビンです。ボビンについては、ミシンの下糸をまくボビンを妻のミシンから失敬しました。
もちろん、空のスペアのものですよ～。
こんな形でできました。
ボビンが空回りしないように中央にスポンジを入れています。
つくっていて色々と気づきました。
・ボビンにはかなりの銅線が巻けるので、ほどほどに。
巻くときはドリルにボビンをつけて回転させますが、直径が太くなるには結構な時間がかかります。
取り替えるのが面倒なので、できるだけ沢山巻きましたが、あまり沢山まくと、巻き解けて銅線が軸にからまります。
巻く量は半分くらいがよさそうです。それに半分も巻けば一生つかえるだけあります。
・銅線をシャーペンの中を通すのが一苦労
いろいろなところにひっかかります。胴体部を通すのも難しい・・・・・。そこで胴体部については竹串をガイドにして通しました。
最難関は先端部分です。これは、ひたすらトライです・・・・。 先端からなら簡単に通るのですが・・・・。
・ボビンの空回り防止が必要。
勝手に回ると、銅線が巻きほぐれてしまいます。それと、銅線が出て行くときの抵抗が小さいと、ピンに銅線をまきつけるのが
難しいです。そのため、ボビンが勝手にくるくる回らないようにスポンジを詰め込みました。
快適！！
いざ、このワイヤリングペンをつかって配線をしてみますが、快適です！
いままでの、電線をつかった配線に戻れそうにありません。銅線を１ライン分を敷設して、最後にまとめて半田するだけで
簡単に配線ができます。
ただ、快適に作業するには、すこしコツがいりそうです。
・半田コテの温度は高めに。
私の場合は４２０度設定です。コテをあててて、半田を流し込んで、しばらくコテをあてつづけていると、被覆がとけたときに
一気に基板のパッドに半田が流れ込み、山形の半田形状になります。反対に、半田が綺麗に流れ込むまでコテを当て続ければ
確実に付きます。
・ＩＣソケットのピンは最初に半田付けしない。
ワイヤリングペンでピンに１回あるいは２回程度、銅線をまきつけたほうが確実に取り付きます。そのため、ピンは半田付けしないほうがいいです。
電源ピンのみ、ＩＣソケットの固定として半田付けしておきます。
・ワイヤーはゆるゆるに配線
ワイヤーはきつきつに張ったほうが綺麗ではあるのですが、半田コテが触れると被覆がとれてしまう可能性があります。
ゆるゆるに配線しておけば、半田づけする位置の配線をピンセットでどかすことができませす。ピンとはってしまうと、
溶けてほしくない被覆がとける場合があります。
結構配線数は多いですが、比較的短い時間でできました。
配線後はテスターで導通チェックをおこないましたが、問題なしでした。
制御線を配線する！
さて、ＲＡＭの増設のベースはできましたがＲＡＭの制御回路を変更する必要があります。
もともとは２ＭＢ実装しか想定していませんでしたので、すこし制御回路も変更しなくてはいけません。
４ＭＢ限定にするなら簡単な変更で済みましたが、折角なので最大８ＭＢまで制御回路をほとんど弄らずに
増設できるように変更しました。ただ、８ＭＢのＲＡＭを実装するには、もう基板のスペースがありませんから、
親亀小亀方式をとる必要があります。しかし、８ＭＢまで増設するかな～・・・といいつつ、ＳＲＡＭは注文しちゃいました（笑。
８ＭＢあっても何につかうの？てな感じですが、まあ自己満足です。
改造前のメモリー部の制御回路です。メモリーの増設は考えていなかったようです。
改造後のメモリーの制御回路です。最大８ＭＢまで増設することを意識しています。
まずはＲＡＭの追加完了！
さて、全体のＨＷの改造は完了しました。
ついでといってはなんでしたが、ＳＲＡＭのバッテリーバックアップ機能も追加しました。簡単に１Ｆのスーパキャパシタを載せています。
これは秋月の福袋にはいっていたものです。５個ぐらいはいっていました。
１Ｆでどこまで保持できるかわかりませんが、あまり長時間の保持は狙っていません。すくなくとも、電源を供給しているＵＳＢの差し替え
程度は保持してくれれば十分です。とはいいつつ２～３日は保持できたら嬉しいな～。これについては、電圧を監視してチェックする必要が
あるでしょう。
ＳＲＡＭの増設が完了しました。ついでにスーパーキャパシタによるSRAMのバックアップも追加しました。
さて、引き続きＲＡＭディスクの容量を増やすべくＢＩＯＳの修正です。これが、また面倒くさいです。
しかし、なかなかオーディオネタに戻れないな～・・・orz
2MByte RAMディスク 実装完了！
BIOS、CPM.SYSならびにPICのシステムプログラムを変更して２MBのRAMディスクの実装が完了しました。
これで、まずはRAMディスク容量は気にすることはないでしょう。たぶん・・・。
RAMディスク（B)のドライブ容量が２ＭＢyteになりました。
バッテリバックアップの状況をみてみよう！
RAMドライブの容量が増えたのはいいけれど、その内容がバッテリーでどの程度保持できるか調べておきましょう。
ちなみにバッテリーであるスーパーキャパシタの供給すべき電流は下記の通りです。
RAM スタンバイ時 4uA × 8 ＝ 32uA
ロジックIC 74AHC138 40uA × 2 ＝ 80uA （-40 - +85deg)
-------------------------------------------
計 112uA
74AHC138の待機電流が読めないところで、+25℃に限定すれば4uA/個です。-40～85℃での最大値が40uAなので
どれが実際の値かはよくわかりません。
あと気になるのはスーパキャパシターからSRAM以外のメイン回路への電流の流入防止ダイオードにショットキーを使いました。
これは逆電圧が小さいためなのですが、ショットキーは普通のダイオードに比べると漏れ電流が大きいです（そのため耐圧が低い）。
これもかなり悪さをするかもしれません。
それにしても、最大値で112uAだとすると１Fのキャパシタでは１日とかは厳しいでしょう。電池を抱かせたほうが
いいかもしれません。
一度、一晩放置してみましょう！
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が起動します。この間の
時間は２～３秒。時間も短いのでリセットへの抵抗はほとんどありません。
でも、よく考えたらマイコンとはいえコンピュータがフリーズしたからといってリセットをかけるのは異常事態です。
WINDOWSのPCでリセット（電源再投入）しようものなら、数分立ち上がりを我慢しなければなりませんし、HDDの中身も
心配です。それを考えたらマイコンといえどもリセットを押すという事態は、できるだけ避けたほうがいいでしょう。
フリーズの原因は？
最初はCPM側の問題と思っていました。というのも、昔のPCなのでもっとのんびりと作業をしないと糞詰まるのだろうな～、
程度に考えていました。CPM68Kになってリセットを押す機会が増えてしまうと、たとえわずかな作業だとしても、システムの再起動が面倒に
なってきます。そこで原因を調べてみました。わかったのはPIC内にRS232をつかうためにUART機能があり、駆動ルーチンはCCSのライブラリ
をつかっていますが、そこに問題がありました。PC（キーボード）からRS２３２でデータをPICに送り、
PIC内のソフトでデータが来たことを確認したのちにデータを取り出すのですが、データを取り出す前に次のデータがPCから来てしまうと、
読み込みのバッファーがないためか、そこでエラーが発生するようです。そこで、システムがフリーズするのもおかしな話ではあるのですが、
データの読み出しにいったら、そのまま戻ってこないということになってしまうようです。
対策は？
原因がわかれば、この対策は簡単です。要は、PICのUARTにデータを溜め込まないようにすれば言い訳なので、
UARTがデータを受信したら、割り込みをかけてデータを読み込んでリングバッファーに蓄えます。これだけです。
そして、データはUARTから直接読むのではなく、リングバッファーから取り出すようにします。
プログラムはいたって簡単。下記の割り込みルーチンをあらたに加えてます。そして、いままで読み出しで使っていた
次のサブルーチン
kbhit() キーボードが打たれたかどうかを返すサブルーチン
getc(c) １文字入力
を、それぞれkbhit2()、getc2()に置き換えるだけです。
リングバッファー処理の割り込みルーチンです。
これで、サイズの大きなコマンドファイルの読み込み中にキーをおしても、フリーズすることはなくなりました。
コマンドが立ち上がったときに、打ち溜めた内容が一気に表示されてくれます。
追加の効能？
CPM68Kではラインエディターしかないので、WIN-PC上のエディタでファイルを作成してRS232経由でファイル内容を送信していますが、
取りこぼしが出ないように、通信速度を38400ボーまで落としているのですが、このリングバッファー機能を入れることで
通常の115200ボーで動かしてもとりこぼしがでないことをがわかりました。案外、こっちの効能のほうが嬉しかったりします。
改行などの制御コードが送られたときの処理速度が、全体の受信速度を律即していたようですが、それが緩和されたようです。
スーパキャパシターの持ちは？
電源を切ってから、１日分のスーパーキャパシタの電圧を測定してみました。結果は下図の通り。
SRAMの内容保持電圧限界は1.5Vなので、２４時間程度は保持できそうです。
スーパーキャパシタの電圧変化。１日はSRAMの内容は持ちそうです。
で、このグラフの曲線から負荷をざっと計算すると、およそ100kΩ程度になります。
ということは、初期電圧5Vとすれば50uAの電流が流れることになります。
SRAMが4uA×8=32uA、ロジックIC(AHC138)が4uA×2=8uAですから、約40uAですからほぼカタログ値どおりですね。
ただし、これから夏場にはいると電流が多くなるので短くなりそうです。
しかし、１日保持できるというのは中途半端だなあ～。瞬停に対しては十分ですが、
しばらくの出張には耐えられません。やっぱり、ボタン電池搭載するかな？ たとえばCR2032だと
公称容量220mAあるので、40uAとすれば5500h、すなわち約230日は持ちそうです。
CR2032の仕様です。これはMAXELLの製品の場合。
（続く？それともPART２になる？） → 次男が誕生しました！ 2020.6.27
一文字違いで大違い！ 2020.7.15
現在使用しているCPUはTMP68301AF-12なので12MHz品だが、オーバクロックの限界を試してみようと
さらにクロックの高いTMP68301AF-16（16MHz)を注文中だったが、届いた品物をみてがっくり。
TMP68301AFR-16が届きました。一文字違いで大違い。パッケージが違います。
どうやっても、現状の基板にはのせられないだろうな～。無理するより、返品して正しいものを送ってもらいましょう。
注文したのはTMP68301AF-16だけどTMP6801AFR-16がとどきました。
パッケージが違うので、載らないです。
人間ワイヤーボンダーだあ！！！ 2020.7.25
とうやら、ショップにはTMP68301AF16の在庫はないようで、返金扱いになってしまいました。
返送は不要らしいです。そりゃ、返送費用が購入価格以上になってしまいますからね～。
で、再度TMP68301AF16の在庫のある店を探してみますが、みあたりません。
国内には１件みつけたのですが、値段が９０００円以上します。まあ、もともとその程度の値段だったのでしょうが、
いまさらそんな大金をだす気はありません。同じ金額だすならRasPi4Bの8GBバージョンがほしいです。
どうしよう？
手元に、返品不要の素子がありますが捨ててしまうのも忍びないな～。折角だから活用できないだろうか？
ということで、今度は変換基板を探してみますが、これもみあたりません。
なんせ、20-30pinの正方形でないチップなので、なかなか該当する変換基板がないようです。
こうなったら自分で変換するぞ！
最近、ポリウレタン被覆銅線をつかうのが楽しくなったのと、下記のサイトをみていて、
0.65mmピッチくらいのICならなんとか手配線できるのは？という気になってきました。
引用：http://elm-chan.org/docs/wire/wiring.html
このサイトをみていたら、自分でもできそうな気がしてきました。
即座に挫折・・・
ワイヤリングペンをつかって、0.65mmピッチのICに配線を開始・・・・・△×□・・・ギャーーーー、、、駄目～！
すぐに挫折です。そんな細かい半田づけできそうにありません。なんせ、見えないだもん！（泣き。
ということで、ワイヤリングペンはあきらめて普通のワイヤーラッピングの線（これは0.3mmくらいある）でやり直しです。
0.65mmピッチでの手配線は全然できそうになかったので、ICの足を1本毎に折り曲げて、1.3mm間隔に広げます。
そのため、上下２段の配線が必要になりますが、間隔が広がった分、半田付けが簡単です。
で、やりはじめて後悔しだしました・・・・。もうめちゃくちゃ面倒くさい・・・・。
でも、最後までやり遂げなくっちゃ！！！人間、諦めたら駄目です(笑。
なんとか完成？
とりあえず蛇の目基板に載るようにピッチ変換できました。でも、なんかあぶなっかしいな～。大丈夫かな～？
なんとか変換基板の完成です。
で、
下の段の配線が取れたらどうしよう？？？
こうなったら三男坊の誕生だあ～！ 2020.7.27
TMP68301AFR-16が2.54mmピッチに変換できたのですが、それをみているとなんとか動かしたくなってきました。
４連休の最後の締めくくりにいいかもしれません。GoToじゃなくて、引きこもりの典型ですね(笑。
色々と部品をかき集めると、なんとかCPM68Kの１台くらいはできあがりそうです。
SRAMは１２nsの高速なものを！
もともとオーバクロックの限界を試してみようとしてCPUは買いましたが、ひょっとしてSRAMの方が先に
追いつかない可能性もあります。そのため、もっとSRAMについてはもっと高速なものをつかったほうがいいかもしれません。
ということでいままでつかっていた4MBitのSRAM(55ns)ではなく、秋月で売っている1MBitですが12nsのものをつかって
みることにしました。１個１００円でした。
で、なんでこんなものが買ってあったのか思い出せないのですが、ひょっとしてメモリーバッファーの検討用に買ってみたのかもしれません。
このSRAMの面倒というか、長短所なのですが入出力の電源とコアの電源が分かれています。
入出力の電源は3.3Vあるいは5Vに切り替えられる特徴があります。それに対してコアの電源は５Vで固定です。
ということで、おそらくメモリーバッファーの場合は3.3Vにしたかったので使うのをあきらめたのかもしれません。
でも、いまとなっては5Vで動く高速SRAMなので、結構貴重だったりします。
まだ、売っているうちに買っておこうかなあ～（←（天の声）だめだめ。部品箱の肥やしになるだけだよ～）
三男坊にはこのSRAMをつかってみましょう。1MBitの12ns品です。
親亀小亀！
配線はできるだけ少なくしたいので、最小構成の２個だけをつかおうかとおもいましたが、２個だと256kBにしかなりません。
これだと、ちょっと厳しいかな～。CBASICのコンパイラはそれだけでも100KB程度あります。OS（CPM68K)に約32kBつかうので
残り100kB程度だとコンパイラー動くかな～。
よし！親亀小亀で４段重ねにして1MBまで拡張できるようにしましょう！
まずは、ICピンの加工です。
このSRAMは内側にピンを曲げた形になっています。半田付けではなくソケットへの挿入を前提にしたパッケージなんでしょうね。
面倒ですが、ピンを先のとがったピンセットをつかって足を引き起こしていきます。大体引き起こせたら、ニッパでまっすぐに成形して、
最後にニッパですこし長いピンの先をすこし切って加工完了です。
あとは積み重ねて半田付けするだけです。
こんな形のPINの形状をしています。昔はこういうの多かったような・・・
PINを成形して長さをすこし短く切りそろえます。
４個重ねて半田付けすれば完成です。１個で512kBのモジュールになります。もちろんCE（Chip
Enable）ピンはまだ半田していません。
STDサイズの基板に押し込めよう！
部品点数もあまり多そうにならないので、ここでは小さくSTDサイズの基板に押し込むことにしました。
まあ、なんとかはいりそうです。
ただ、あまり触りたくないCPUや背の高いSRAMがありますので、基板をひっくりかえしたときに安定するように
基板の４隅には25mmのスペーサを立てておきました。
なんとか必要な部品はSTDサイズの基板の上におさまりそうです。
配線準備
いままでは、即座に基板をうらがえしにして配線を始めていましたが、なんども配線間違いを起こして無駄な時間を費やしていたため、
最近では予め、裏側からみた場合のピン配置図をつくっておくことにしました。これ１枚あるだけで、だいぶ効率化がはかれます。
作成はEXCELをつかった書きます。まずは部品面から見た図を描きます。エクセルで左右を反転させる方法がわからなかったので、
まずは行列を入れ替えてコピーをつくって、それの上下を反転させます（これはデータのソートでできる）。そして再度、行列を入れ替えて
やれば、左右反転の図ができます。ただ、罫線が消えるようなので、あとで罫線は再度かきかきします。
最初に裏側からみたICのピン配置図を描いておくと、配線間違いを防止できます。
夜鍋作業・・・・
あとは、ビールを飲みながら、手を動かしていきます（笑。
酒っておかしなもので、最初のみ始めるとだんだん眠たくなってくるのですが、ある時間を過ぎると逆に目が冴えてきますよね～（って、同意を求めないように（自戒）。
軽くBGMも流して、そして半分酩酊しながら、半田コテをにぎるのもおつなものです。
なんせ、素面だと間違えないように慎重になってしまいますが、酔っていると気分が大きくなるので、
「たぶん大丈夫！」ってな感じで、どんどん作業が進みます(爆。
完成しました！
流石に眠たくなってきました。動作確認は明日にしましょう。
動作確認しただしたら、絶対に太陽がのぼっちゃう・・・・・
動かなければ、動かないで原因調査のために時間がかかります。
動いたら動いたで、さらに色々とやりたくなってしまって時間がかかってしまいます。
まあ、今日（？）は大人しく・・・明日もあるし・・・。
動作確認！
さて、いよいよ緊張の電源投入です！ソフトはCPM68K次男と同じものをインストールです。
次男もメモリーが１MBなのでBIOSも同じでいけるはずです。
電源投入！ まずはモニタープログラムが起動します。ここまでは大丈夫。そしてCPM68Kを動かすコマンドを入れますが、
うんともすんともいいません。気がつけば、CPUのクリスタルを挿すのを忘れていました（笑。
そして、まずは適当な10MHz程度のクリスタルを挿入して再度、電源ON! やっぱり動かない・・・。
各パートごとに原因調査です。
・SDカードの読み書き・・・問題なし。
・メモリーチェック・・・・問題なし。
あれ？メモリーまでうまく動いているのに、何が？？？？ で、配線を眺めているとCPUの変換基板の部分で
ラッピングワイヤーが１箇所クロスになってつながっているところを発見です。やっぱり酔っ払いながら配線すると、
やることが適当になってしまうようです。
で、それを修正したら無事動きだしました！
オーバクロックに挑戦！
さて、本題のオーバクロックに再挑戦です。CPM次男では50MHzまで動作を確認できましたが、
今回はどうかな？
水晶発振器をSi514に変更して周波数を可変にしてオーバークロックをテストです。
結果は・・・・・
５０MHｚ・・・×
まずは次男の実績である５０MHｚからチャレンジ・・・・・結果は×です。うんともすうんとも動きません。
ちょっと残念です。目標は次男越えだったので・・・・。
４５MHｚ・・・・○
つぎはすこし落として45MHzです。これは無事立ち上がりました。わずか5MHz（10%の差）ですが大きいですね。
で、このときの発振器のオシロを観察してみるとかなり大きなオーバシュートとアンダーシュートがでています。
ひょっとして、これが悪影響を及ぼしているかもしれません。ダンピング抵抗をいれて波形を改善したら
もっと早く動けるかも・・・・・
かなりオーバーシュートとアンダーシュートがでています。
４５MHｚ・・・・×（ダンピング抵抗あり）
ダンピング抵抗（５１Ω）を入れてみました。オシロの波形は幾分綺麗になりましたが・・・・動かなくなってしまいました。
おそらく、オーバ・アンダーシュートするくらいの波形でないとだめだったということかな～。
ダンピング抵抗をいれたら波形は綺麗になりましたが、動作せずです。
結果的には45MHz（それもダンピング抵抗なし）がギリギリ動くということになりそうです。
次男にちょっと負けちゃいました。
まあ、もともとCPUのスペックが最大で16.6MHzですから、それ以上となると限界値はかなり個体差がでてくるでしょう。
まあ、45MHzでなんとか動くようなので、実運用は33MHzくらいなら大丈夫でしょう。
それにしても・・・・・
CPM68KでC言語のコンパイルをSDカード上でやると、無茶苦茶時間がかかります。
やはり、つかって行こうとおもえば（あまりその予定はないですが・・・）、RAMディスクは必須というところです。
折角、三男坊までできましたが、当面は部品箱の中にしまいこまれそう・・・・。ご
ごめなさい・・です。
（つづく？）