環境構築の続き。予想どおりなかなかに進みません（溜息）：
タイトル通りの有様ですが俗に言うLチカ相当に近づきました（長かった、というか永い）。
・虫取り環境の図
m68030_v0（以下本機）は楽したいのでISP可能なチップを使用しています（Obsoluteですが）：
・CPLD(XC95108)：XilinxのCPLD ISE14をUbuntu24.04でverilogで開発し、iMPACTでISP（写真下のXILINXロゴの中華コピー品で書込み）
・PSD(PSD854)：STのFlash/SRAM/IO/PLDを集積したもの。PSDSoftExpressでAbelで開発し（Ubuntu24.04でVMWareのXP上で動作）RasonanceのISP書込ツールでISP
・MCU(PIC12F1501)：MicrochipのPICmicro。16us,4msのクロック生成に使用。MPLABXのPICKITでICSP（写真にはありません）
・ロジアナ（LA1010)：ディジタル回路で動かない時はこれに頼るしかありません。当初AD2を使うつもりだったが諸事情で１万円の中華ロジアナを入手して使用。個人的にはマニュアル含めて良く出来ていると思います（100Mhz/3ch,50Mhz/6ch,32Mhz/9ch,16Mhz/16chと合理的）。写真右上
Lチカなので次はLED（右上）が点灯（点滅）している写真をば：
写真右上の点灯（点滅）しているのがLチカ（点灯状態：）。LEDは上記PSDのPB7に接続されています。
次はタイミングで上記LA1010で取得
CH0が32Mhzのsystem clockでCPLDのステートマシンで使用している。1/2してCPUのクロック生成。
・CH0：system clock (32Mhz)
・CH1：/reset
・CH2：CPUの/as
・CH3：PSDの/cs
・CH6：/rd
・CH7：/wr
・波形取得に使ったテストプログラム（抜粋）：
sram(28KB)のwrite/readテスト、0x20〜0x7f(表示可能なASCIIコード)をFT245経由でCDC-ACMにてターミナルに出力する。
（ram test ptn),(PSD input port),のフォーマットで表示しています。なので
4D A5 4E 25を例にすると：
・4D：ramテストパタン（ASCII）
・A5：bit7が1、PB7のLED off
・4E：ramテスト（0x20〜0x7fを繰り返し）
・25：bit7が0、PB7のLED on
こちらはPSDSoft Expressの画面（Ubuntu24.04hosted VMware/WinXPで動作）で右はPSDAbelで生成されたコード、左上がPSDにISPする画面。プログラムはaslなりgccで作成した物をIntel hex（ここ重要！）にして画面左下のmerge MCU/DSP firmwareでPLD/IOとマージされたCOFFファイル（懐かし）を生成し（左上の m68030_v0.objが相当）それをJTAGでPSDにISPする仕掛けです。Flash含めてISPなので私の如き猫型人間には好適ですがObsoluteなDevice故（以下略）。
・まとめ（或いは教訓）
１．PSDSoft ExpressはFirmwareを取り込む際にIntel hexとMotorola S-format
を選択可能（にみえる）が、Intel hexしか受付けず Motorola S-formatはエラーとなる。当初（68030はmotorola故）S-formatを指定し且つエラーメッセージに気付かなかった（不覚です、弁解の余地なし）のでプログラムを弄ってもReset Exception後のFirmwareの動きが不安定（プログラム書かれていないので当たり前：）でこれに気付く迄相当時間が掛かりました。１６年前のhc11にbuffaloを書き込んだ時の教訓が生かされていない
というか完全に忘れておりました。
２．さまざまなCPLDのバグをISE→IMPACTでISPを繰り返して虫取りを続けているわけですが散発的な動作不安定（突然死したり）する。パスコン・電解コン付けたり対策継続中
３．MPLABX v6.10以降（202504時点の最新バージョンはv6.25）ではPICKIT3はサポート対象外（というか打ち切り）でPICKIT4,5,MPLABX Snap等を必要とする様です。今回、gemini2.0にRA4に16us,RA2に4msのクロックをPIC12F1501で生成したいと呪文を唱えてそのCコードを基にデータシートを眺めつつ修正しました（〇〇と鋏は使いよう）。
という事で（継続中ですが）今回の教訓まとめは、
トラブルはやってる人間（＝私）のレベルに応じて起きる（起きた）
というオチでありました（反芻）・・・
20250418 22:20追記：GTKTermではhex inputというのが有ってhexadecimalでの入力が可能です。例えば、00 05 00 00<cr> で FT245に 00 05 00 00のバイナリデータが送信され、それを例えばアドレスとすれば超簡易型のメモリダンプが実現出来るのではと考えた。テーゲット側の動作としては、
・FT245で4byte(32bit addressと見做す)を受信する。
・それをメモリアドレスとして例えば256byte FT245に書き込む（GTKTermに送信する）
といった超簡易型メモリダンプ（大袈裟に言えばAgent的な・・・）のプログラムを書いてみた（抜粋）↓
表示は取り敢えず２５６バイト、画面左の数字はGTKTermが付与するindexに過ぎないので情報としては意味無し：）
な訳で超簡易型メモリダンプもどき：）でありました。こんなレベルでウダウダしてるのはUniversal monitorの移植が難航している為で（またもや）ハードの問題かソフト（移植）の問題か切り分け中で・・・
トラブルはやってる人間のレベルに応じて起きる（反芻）
20250419 13:05追記：今度はm68k-uclinux-gccで似たようなプログラムを書いてみる。参考（深謝！）とさせて頂いたのは下記サイトです（御礼申し上げます）↓
２０１２年にMC68000ボードを作成されてuClinuxを実装された方のサイトです。ソースも開示されていてUbuntu20.04/22.04/24.04のm68k-uclinux-gcc他toolchainでbootloader（即ちgccでのROM化）の大変有り難い実例であります。特に参考になったのはstartupルーチンとリンカスクリプトでこの情報のおかげでCrossGCCの沼：）で迷子にならずに済みました。
PSDのFlash/sram容量の関係でROM:32KB,RAM:4KBとしています：）
恥ずかしながらm68k-uclinux-gccでのROM化は初めてだったので上記サイト様のおかげで思いの外スムースに作業出来て有り難かったです（何度でも感謝）。
最後に生成されたコードの逆アセンブル（m68k-uclinux-objdump -d bootloader >bootloader.lis）
20250420 18:00追記：gccでテストプログラムを書いているとどうも大きい（数百行以上？）だと正常に起動せず（多分double bus fault？）また切り分け（最近の私のパワーワード（正負は別にして：））をしていたのですが、ふと回路図を眺めていると・・・
PSDのA11がA10につながっている（A10は正しくA10）になっているのを発見（しょんぼり）。Kicad（Eagleサブスク停止したので）でパターン見てみると
図中P42がA10（正しくはA11）でP41(A10)とP42(正しくはA11)がしっかり接続されておりました（酷いな）。レイヤを確認すると
KicadとEagleのオートルータは異なるので実物を確認しつつ表面層ならばパターンカット出来そう。但しソケット外す馬力ない（吸取機持ってない）ので仕切り直しで２枚目の基板に改造、実装をするつもりです（涙）。
トラブルはやってる人間のレベルに応じて起きる（座右の銘入りか）
20250421 16:11追記：実物のベアボードでP42-P41のパタンが上記図面どおりである事を確認。表面層で良かった：）
