２０２５年、令和七年も今月でおしまいといふことで全然関係無い近況を適当に記します。柔らかめな文体でご容赦の程。
１．今月の基板
今月とは２０２５年１２月を指します。JLCPCBに２回めの発注した物が送られて来たので外観検査後に納品処理をば：）
ご覧の通りJLCPCBに発注したものです。
・１２／９：発注⇒１２／１１出荷⇒１２／１５入手（OCS黒猫、ポスト投函）だったのでDoor to doorで６日とpcbway並のリードタイムの場合もある様です。
・外観検査ですがシルクはpcbwayよりくっきりした印象（別段情報量に差は無いのですが）、レジストもfusionpcbの様なマットではありませんがpcbwayのテカテカでも無い、悪く無いです（良いの婉曲表現）。
実はこの基板はDIP主体で１００ｘ１００ｍｍに当方のスキルで実装するとどの程度の規模の回路迄行けるかを実験したかっただけで発注する気は無かったのですが、よく有る話で折角基板設計したからJLCPCBのトライアル（２回目）も兼ねて発注した次第。ロジ込みで４USD弱とは犯罪的な価格設定（pcbwayの１／３です）。
あと何回か発注してリードタイムを掌握出来たら・・・と考えております。
＃それで問題無さそうであれば・・・JLCPCBを主に、pcbwayを副にするかもしれません。。。
実はJLCPCBは部品DBが豊富でPCBアセンブリ（まあ、SMD部品実装を想定しているのですが）をお願いするに好適とgemini2.5の神託を受けて準備を進められたら（鬼が笑うお話ですが）と思ったりしています（もうSMD部品実装なんて不可能なので）。
ブロック図ですがまだPLD考えて無いし、ごくごく凡庸な6809E/6309EのSBCなので説明は省略。想定はFLEX9を動かせば目標達成、みたいな・・・正直優先度は低いので積読状態になる可能性が高い（多分来年になっても同じ事言いそうな予感）。
企画背景が不純なのでノスタルジーだけで組み立てる気力はいつになるのだろう・・・
とか言いつつパターン図（全レイヤ合成）も貼り付けておこうか。
６８０９ボードなんて４０年振り：）
２．MC68HC11F1でFuzix移植（できたらいいな）
hc11f_v1のハードウェア基本動作を行った後、放置してたので目的のFuzixの移植をボチボチ始めようかなと
秋月のマイクロSDカードモジュールからビルドしたディスクイメージを読み込む様にはなったのですが・・・コアダンプしたり奮闘中（がんばろう）。。。
前回と同じ基板なので差分を記述すると、
・TTLシリアルケーブル（USB-serial変換、HC11のSCIと接続）を装着・動作確認（画面左上からの黒い線）
・Fuzix image（dd if=sd.img of=/dev/sdf で丸ごと書込み）をマイクロSDに書いて、その媒体を装着した状態（画面左下）
・ハードウェアのバグを見つけたのでISPで修正（画面右上の14pinケーブルでISP）
でボチボチ作業を進めて（試行錯誤して）おります。
ビルドしたfuzix imageを上述の様にsd.imgをddしてそれを実機に装着してローダ読み込んで起動・・・を繰り返すという非効率なデバッグ（というか試行錯誤）の沼におります（涙）。
煩雑ですがbootloaderをdbaでファイルからロードし、それを実行してマイクロSDからfuzixを起動（したい）という形です。マイクロSDはビルドしたsd.imgをUSB接続の何でもカードリーダ（中華製）で書込み、これを無限に繰り返す（無限デバック状態：）・・・
上図が格闘中の画面でありまして、色んなエラーでコアダンプを吐きまくりで何がどうなっているのか手探りが続く・・・画面下は一見ブートしている（確かにSDカードのアクセスランプが点滅しメモリ上に読み込みはしているのだが）がそこでだんまり状態と予想はしていたけどなかなかに手強い（いや、当方のスキルが低すぎて苦戦しているだけなのかもしれませんが（その可能性は高い））・・・
loadsd.Sというローダとsdcardのファイルシステムのドライバ（というかspiでsdカードをrwする下請け関数が機種依存ファイルとして纏められている）が動作しているのか？？？な状況。
＃８ビット系のfuzixはバンクメモリが前提であり、68hc11ではPAｎで上位アドレスをPortAに割り当てて64K毎にバンク（つまりMZ80Bの如くROMが消える）切り替えでメモリを確保する（なので512KBのsram搭載）ので通常のデバッグモニタ（buffalo等）でbp張ってromデバッガで静的デバッグとは行きにくい（いや、当方のデバッグスキルが無い為かもしれません、きっとそうだ）のでリンカマップとロジアナつないで実行しているアドレスからステートアナライザ風（アドレスだけだが）に実行中の番地を特定し、それとリンカマップを照合して該当プログラムを推知する・・・といった有様なのでソースの理解とhc11fのgpio(portG等）に状態出力してledでも繋ごうかとか考えたりしております（あな、懐かし）。
仕事なら胃が痛くなりそうですが所詮は個人の道楽（老後の楽しみ）なので結構愉しい印象、ツールもコードも手製なので粗末ではあるが中身が解っている道具は案外それなりに頼りになるものです（自賛ですな）。
仕事ならICEとかjtagデバッガを確保するのでしょうけど道楽なので手持ちのツールを組み合わせて（知恵出して）ごにょごにょと・・・
幸い６８００の機械語は読めるのでHC11の追加命令（Yレジスタ関連）はマニュアルと突き合わせる（まあ、18 xxなので予想は付くが）のもまた愉しであります。
＃ああ、８ビット系のFuzixはアセンブラコードが結構（下半身系はほぼ全て）多いので一番馴染みがあるMC6800の直系のMC68HC11F1を選んだのですが・・・オリジナルのHC11Aのコピペの方が楽出来たかもしれないけど・・自爆して体動かして覚えるのもまた楽しからずや、であります（あはは）。
つづく
20251219 01:57追記：kprintfが動く様になった。
最後の行の＠はloadsd.Sで追加したマーカ、そしてfuzix_main[0]がstart.c(fuzix_main())に記述したdebug文です：）
アセンブラからCになれたかと思いきや、TTYのopenで固まっている模様（trapしてないのでループしてる可能性）。
見にくいですが上図３５２行の d_open()が帰ってこない様です（pb7(LED)トグル関数とkprintf()で確認）。なのでファイルシステムの前にTTY（sci）周りを調査しなければ・・・頑張ろう：）
d_open()が正常終了したらその下の起動メッセージが拝める筈（がんばろう）・・・
他にもハード要因でsdcard挿入するとボードにリセットが掛かる（所謂sdcard挿入時の突入電流の可能性）ので秋月モジュールの3.3V系は・・・コンデンサはユーザ選択（DNP)らしい・・・偶然セルフパワーHUBを調達していたので試しにセルフパワーHUBからの供給で抜き差しするとリセットは掛からなくなった（ような、リセット時にpb7(LED)を点灯してるのでそれで判定。）。
これで動作が論理的（操作してないのにpb7(led)が点灯／滅灯等の不気味動作をする症状も解消。突入電流／負荷変動を舐めてはいけません（反芻）。）になってきたのですが・・・
つづく
20251222 02:49追記：uSDの3.3V系に突入電流対策で負荷コンデンサ220uFを追加しました。portGのピンヘッダを付加し、アドレスモニタ用にロジアナ（LA2016)をセットアップしました↓
図中左中の点灯しているLEDがportGのled（白、青）であり、上がロジアナ（LA2016：200Mhz,16ch）であり、左下の秋月uSDモジュールのpin3-4に220uFの電解コン（Amazon中華部品なので普通の電解コン）を寝かせてハンダ付けしました。波形を見てないので充分かは不明ですがリセットしたり挙動不審は解消された様に見える。
動作確認の為にバス（a0-a15を見るだけ、トリガ用にportGをch15に入力する場合もある）をモニタしました↓
波形ではなく画面右の16bit hexの情報がアドレスバス情報です。hc11では無効アドレスは0xffffを出力する場合がある（相対アドレス計算など）ので相応の情報が出力されています（念の為に素性の知れてるdba起動時にモニタしたら0xfdax辺りをうろついていたので大丈夫な筈）。bit15はトリガとして使っていたので0 or 1と解釈して・・・
これでfuzixソースにportg(0x40)等のデバッグ用関数を付加してledなりロジアナトリガとして出力し、ロジアナでアドレスをモニタしたのですが・・・
０ｘ００９E〜A２ってfuzix.mapに登場しないのだが（所謂ゼロページ）・・・とはいえ暴走している訳でも無さそう（illegal instベクタには落ちていない様なので・・・１００％の確信は無いのですが）な印象。
fuzix_mainでd_openを呼んだ際の validdevが返って来ない（kprintfでもportgのledも表示されないので）最近バージョンアップされたgemini3にfuzix.elfを逆アセンブルしたファイルからd_openとvaliddevの逆アセンブルリストを食わせると、関数呼び出し作法が合っていない（stackに積んでるのにレジスタで返している）とのご神託でMakefileでのオプションを確認し、Makefileのコンパイルオプションを機種依存部とfuzix共通部を合わせたが・・・見た目の状況は変化なし（まだまだ：）↓
kprintfは日本語通る様なので少しは見やすくなった気も、d_open(TTY,0)でttyは512+1と定義してあるのでそこまでは伝わっている模様だが・・・validdev()で別世界に旅している（０ｘ９E〜０ｘA2の零ページの世界に）・・・これもある種の暴走でしょうか？
こういう状況はブログネタとしては美味しい（本人的にはそうでもない）のかもしれませんが進捗が無いのが辛い。最後はdebug環境のスクショで誤魔化しておこうか（すみません）。
gemini3(fast)は上記 validdevをアセンブラで書け（stackの矛盾を解消する為に）とかなかなか意欲的な提案をしてくれる（ある意味生意気）が・・・それに乗ってみるのもまた楽しからずや・・・逆アセンブルリスト精読するなんて何十年振りだろう（しみじみ）。
最後にソフト開発環境のスクショを貼っておこう↓
画面左がテキストエディタで右上がmake,ddするコンソール、右下がgrep等で色々漁るコンソール画面。原始的ですがIDE使いこなせないので：）
そういう訳でまだまだ続くのでありました・・・
つづく
20251226 06:22追記：どうにかfuzix起動にたどり着きました：）
原因は以下の通りでありました。
１．d_open でaccdの処理を ldd 2,x とコードを生成すべきを clra;ldab 2,x ;という最適化したつもりがaccbの下位バイトを考慮しないコードを生成（する様な記述をしていた）した為、dev_tab[]のアドレス／オフセットが破綻して暴走してしまった。
２．hc11f1（eeprom内蔵チップ共通）はeepromをデフォルトで0x0e00-0effに配置される事を忘れていて、同領域がramとeepromが競合していた
に集約されます。
まあ、何と言いますか・・・わかってみれば・・・といっても１．の対策はgemini3に考えてもらった（gemini3(fast)さん、色々シバいてすまなかったが結果が出たので感謝してます、ありがとう：）
という事でhc11f_v1でMini11ベース（オリジナルは68hc11a）のmc68hc11f1ボードでfuzixが動く様になってとても満足しております（これで今年の目標達成、みたいな：）。
まあ、時計が早く進むとか色々調べなければならない事柄も出ておりますが、まづはfuzixがmotorola mc68hc11で動く環境を構築できて良かった〜、としばし感慨に浸る事にします（良かった良かった）。
20251226 10:40追記：時の流れが異様に早い件：）main.c（機種依存部分）に以下のコメントが↓
で、hc11のマニュアルからtmsk2のbit1,0のプリスケーラを11とすれば1/16になるが、このレジスタリセット後の64clock以内に設定しないと駄目仕様（車載・産業用想定の組み込み仕様らしい。この辺の技術思想は４０年前の設計とは思えぬ程洗練されている）なのでrom側で対応しました。
何となく現実世界の時間に戻って来た様なのでこれで由とします。
20251226 17:27追記：５時間程動かしていたので、fsckが走らないで済む様にshutdownする↓
Halted、illegal instructionが出ていないTrap画面初めて見たよ（びっくり）。
fsckはCPU性能が出るのですごく時間が掛かります（分オーダ）。こういう処にCPU性能差は現れますが・・・まあ、fuzixって現時点の当方の認識では教育・啓発的なポジションの様にもお見受けするので全く気にしておりません。
そもそもfuzixで何するの？何出来るの？ に対する当方の返答は、
それはretro sbc を愛でる為ですよ（どやっ：）
と申しておきましょうか（あはは）。
Old and New （2014年をnewと言えるかは別にして）と申しますか４０年前のマイコン（それもMC6800の直系）でfuzixが動くというのは何度申しても愉しい嬉しいとニヤニヤしている変なおっさんでありました（お解りですよね？）。
20251227 03:49追記：8Mhz(2Mhz cpu clock)で安定性確認出来たと思われるのでクロックアップに挑戦しました（Overclockではない点に注意）。手順は、
１．main.cのCLK_PER_TICKを２５００⇒５０００に変更し、ビルド、MicroSD作成
２．クロックが２倍になったのでターミナルのボーレートを９６００⇒１９．２ｋに変更
３．hc11f_v1のOSCを８Mhz⇒１６Mhzに換装
４．電源導入でdba起動後、bootloader.binをロード・起動
５．fuzixが起動されるか確認
といった順番になります。
そして起動した画面（いや、普通と変わらないのですが）がコレ↓
マニュアルにもちゃんと２４Mhz（６Mhz）迄記載されております↓
まあ、仮にスピードランクが正規分布からのセレクト品と仮定するならば常温（０〜７５℃）で１６Mhz（cpuclk=4Mhz）で動作するのは有る意味当然かなと（無保証ですよ：）。
そういう訳で２倍速は普通に出来そう（連続テスト次第ですが）でそのまま２倍になってる（ボーレートもSPIクロック：SDカードアクセス：も）ので当てになりませんが体感上は速くなった（まあ、ボーレートが大きいのかもしれません）印象が少々。
上記の通りOSCを２０Mhz（５Mhz）、２４Mhz（６Mhz)と上げる事は可能ですが、２４Mhzではeepromとadcは動作しないそうなので実験上の上限は２０Mhz（cpuclk=5Mhz）でしょうか（あくまでユーザリスクですが）。
単純に周波数というか倍率の問題なので速ければそれに越した事はないので問題なければ４Mhz（１６Mhz)にしようかと考えております。
因みにrom(psd834f2j90)のアクセスタイムは９０ｎｓ、４Mbit SRAMは５５ｎｓぐらいなのでE=4Mhz=250nsなので余裕です：）５Mhz(20Mhz)迄は仕様上行ける可能性がある（元祖秋葉原さんで調達したMC68HC11F1がどこまで動作するか分かりませんが・・・なので道楽であり、ユーザが負うリスクといふ事で納得の上での行動ですよ）。
