GOTEKのディスプレイとロータリーエンコーダを本体の外にも増設しました
この状態で2年近く使用してきましたが、流石に不便なので思い切って改善することにしました。
![]() |
| 右上が増設したケーブル |
![]() |
| ケースに格納した状態 |
増設した外部コントローラです。
![]() |
| 右上が増設したケーブル |
![]() |
| ケースに格納した状態 |
未使用だった128KBメモリの残り半分を使用できるように回路を変更してみました。
これが製作した第2版の基板です。
![]() |
| 拡張RAMの配置 |
![]() |
| バンク切り替え回路 |
![]() |
| 実行結果 |
【2024年9月14日訂正】下記のリンク先が間違っていましたので訂正しました。
今までにFM77AV40用増設RAMカードとして、(1)512KBのSRAMを1個使用したもの、(2)512KBのSRAMを2個使用したもの、(3)(2)の上位256KBを無効にできるスイッチを追加したものという3種を製作してきました。
(1)https://flexonsbd.blogspot.com/2022/10/fm772040512kbram.html
(2)https://flexonsbd.blogspot.com/2023/07/fm77av401024kbram.html
(3)https://flexonsbd.blogspot.com/2024/03/fm-777rs232cft2451024kbram.html
FM77AV40の拡張メモリ容量は最大768KBですので、512KBのSRAMを2個使用すると最上位の256KBの扱いが気になります。ただ無視されるだけならそれで良いとはいうものの、それでも勿体ないという気持ちも多少残ります。
使用していて特に不都合はないので、それで良しとすればそれだけのことなのですが、気持ち的にすっきりしないので、いっそのこと128KBのSRAMを2個使用して、512KB+128KB+128KBで768KBの拡張RAMカードを作ってみることにしました。(秋月電子で128KBのSRAMが安かったというのもありますが、ちょっとやりすぎではありますね、、、)
製作したカードがこれです。SOPチップのハンダ付けにもだいぶ慣れてきたようです。なお、富士通の48ピンコネクタは現在ほとんど入手不可能です。ここでは知人が32ピンのコネクタ2個からニコイチで作成されたものをいただいて使用していますが、全く不都合はなく使用できています。表面にスモークのシートを貼っていただいているので、見かけも全く違和感がありません。
![]() |
| 768KB拡張RAMカード |
回路図を示します。
![]() |
| 768KB拡張RAMカード |
アドレスデコードについては前回同様GALを使用しましたが、そのプログラムを下記に示します。
![]() |
| GALのプログラム |
OS-9LevelIIのmfreeコマンドで容量を確認しました。最上位の8KBが削られているのは今までのRAMカードと同様です。
![]() |
| 容量を確認 |
これでFM77AV40の拡張RAMカードについては最終形にできそうです。
(1)クロスアセンブラ
・6809クロスアセンブラ 6809AsmWin.exe
・6800クロスアセンブラ 6800AsmWin.exe
クロスアセンブラの主な修正点はFCB疑似命令のオペランド処理の改善です。
「'A',-'B'」や「'A,-'B」のような両書式に対応しました。また、カンマ「,」やスペース「 」もそのまま「','」や「',」の形で使用できます。ただし、文末にカンマやスペースが来る場合は誤変換が生じる場合がありますので、「','」のように閉じの「'」をつける必要があります。
(2)クロス逆アセンブラ
・6809クロス逆アセンブラ 6809DasmWin.exe
・6800クロス逆アセンブラ 6800DasmWin.exe
逆アセンブラの修正点は、データ部をスキップさせる場合の範囲指定処理の改善です。
(3)転送ツール
転送ツールとして良く使用するのは仮想ドライブ構築ソフトです。それぞれのDOS(?)に合わせて4種類制作しています。
・Flex9用のFlexDrvWin.exe
・OS-9用のOS9DrvWin.exe
・F-BASIC3.0用のFBasDrvWin.exe
・CP/M-80用のCpmDrvWin.exe
主な修正点は、扱えるファイル書式を.D77、.DSKに加えて、各セクタの先頭に16バイトのセクタデータを付加した.DAT形式に対応したことと、パソコンとの通信にRS232Cに加えてFT245高速通信カードに対応したことです。
(4)ツールソフト
・CnvTxtTl1Src.exe
Windows機で作成したTL/1やGAMEのプログラムをTL/1形式やGAME形式に変換するソフト
・CvtMotHexBin.exe
バイナリファイルをBin, Hex, Mot形式に変換するソフト
・CvtDskD77.exe
フロッピィディスクイメージの形式を変換するソフト
その他として、
(5)FT245高速通信カードを用いたFM-7とWindows機との間の高速通信ソフト
・ディスクコピープログラム(F-BASIC3.0用、OS-9用、FLEX用、CP/M用)
・ファイルコピープログラム(F-BASIC3.0用、OS-9用、FLEX用、CP/M用)
がありますが、その都度ブログで報告していますのでそれらをご参照ください。
各ソフトを画像で紹介しておきます。
(1)クロスアセンブラ
アセンブルしたいファイルを「ファイル名」ボックスにドラッグ&ドロップして「アセンブル実行」ボタンを押します。
| 6809AsmWin.exe |
| 6800AsmWin.exe |
アセンブルしたいバイナリファイルを「ファイル名」ボックスにドラッグ&ドロップし、「オプション」メニュー中の「オフセット指定」でスタートアドレスを設定してから「逆アセンブル実行」ボタンを押します。
バイナリファイル中にデータ範囲があるようなら、その範囲を推定して「オプション」メニュー中の「スキップ範囲追加」で設定します。
| Os9DrvWin.exe |
| CpmDrvWin.exe |
| FlexDrvWin.exe |
| CnvTxtTl1Src.exe |
![]() |
| CvtMotHexBin.exe |
| CvtDskD77.exe |
(前回もこのような文を書いておきましたが、特に連絡をいただけることはありませんでしたので、恐らく使用されてみた方はいらっしゃらないのだとは思いますが、自分自身の試みの記録を兼ねてブログにアップしました。)
2023年7月4日のブログ「コンパイラ作成の試み その2 言語の拡張(コメントとFOR文など)」(https://flexonsbd.blogspot.com/2023/07/for.html)の続きです。
| ブログ用画像の表示のために置いてあります |
その際には、繰り返し変数が初期値の次の値から始まってしまうという不具合があり、スタックを使用している言語のため、初期値、終了条件、増分を順に読んでいくしかないので、それが解消できないようだと書きました。
そのため、このマイクロCコンパイラを6809用に改造しようという意欲が失せてしまい、そのまま放置してあったのですが、GAMEインタプリタ・コンパイラの移植、TL/1コンパイラの移植が完了しましたので、これについても何とかしたいと考えていました。そんな時に手持ちの書籍(末尾の参考文献)を読んでいましたら、FORステートメントの実装の説明として、下図のFOR生成2のようなコード生成方式の方が実装が簡潔化できるとありました。
![]() |
| 2つのFOR生成方式 |
なるほどと思い、この形で実装できないかと試みてみました。具体的には、必要な個所にラベルを設定し、そのラベルへのジャンプ命令を追加することで、処理の順序を変えることができました。
そのプログラムを示します。
このようなサンプルプログラムも正常に動作しました。
これで必要な(と思われる)拡張が済みましたので、次はいよいよ6809用コンパイラへの移植ですが、このコンパイラはデータ幅が16ビット、レジスタも16ビットを想定していますので、そのままでは6809への適用はかなり難しそうです。
しかし、TL/1コンパイラのようなデータ幅が8ビットのコンパイラもありますので、まず第一段階としてデータ幅やレジスタが8ビットでも動作しないだろうかと考えました。
それを確認するために、コンパイラが生成した仮想CPU用のアセンブルリストを手作業で6809のアセンブルリストに書き換えて走らせてみました。いくつかの注意点がありましたが、ほぼ機械的に書き換えることができました。使用したのは上記のサンプルプログラムからfor文を取り除いて短くしたものです。コンパイラが生成したアセンブルリスト(.CS)と手動で書き換えた6809用のリスト(.TXT)を示します。
仮想CPU用のアセンブルリストです。
バグの原因は、STA n,Xというインデックス命令でした。6800ではnは8ビット範囲であるのに対して、6809ではnが0~7Fの範囲では5ビット命令となるのです。TL/1ではSTA n,Xのnを動作中に書き換えるというコードを多用していますが、例えばnを0から1ずつ増やしていくと15までは正値ですが、その次は負値の-16になってしまうのです。
6809ではアキュムレータオフセット命令がありますので、
6800での命令 → 6809での命令
(2命令で計5バイト) (1命令で2バイト)
STB xxxx (xxxxはnのアドレス) STA B,X
STA n,X
という計5バイトの命令を2バイト命令に置き換えることができ、これでバグを解消できました。
| 使用した6802/6809デュアルボード (ブログの画像表示のために入れてあります) |
![]() |
プログラム作成・コンパイル・実行手順 |
改良版を製作したのは次の3カードです。
1.RS232Cカード
D-Sub9ピンコネクタに加えてTTL-USB変換ケーブル用コネクタを増設
2.768KB拡張RAMカード(1024KB拡張RAMカード改め)
512KBのSRAMを2個搭載で1024KBですが、最上位の256KBを切り離して768KBにするジャンパスイッチを増設
3.FT245高速通信カード
制御・データアドレスとして使用しているアドレス$FDFD,FEを$FD06,07に変更
1.RS232Cカード
2019年10月26日のブログ「FM-7/77用RS-232Cカードの改良版」https://flexonsbd.blogspot.com/2019/10/fm-777rs-232c.html
などで紹介したものです。D-Sub9ピンコネクタが使用されているのですが、現在では、Windows機と接続するケーブルとしてはシリアル-USB変換ケーブルではなくTTL-USB変換ケーブルを使用する方が便利ですので、それ用の6ピンコネクタを増設しました。これに伴ってシリアル変換ICも実装不要になりました。
右上の6ピンソケットが増設したコネクタです。
| RS232C_R1.2 |
| 右上が増設したコネクタ |
回路的にはただ単に8251からコネクタへ信号線を引き出しただけです。
| RS232C回路図 |
| 使用したTTL-USB変換ケーブル |
2.768KB拡張RAMカード
2023年7月16日のブログ「FM77AV40用1024KB増設RAMカードの製作」https://flexonsbd.blogspot.com/2023/07/fm77av401024kbram.html
で紹介したものです。対象のFM77AV40では増設できるメモリの最大値は768KBなので最上位の256KBは使用されません。無視されるだけで問題は無いとは思いますが、何となく気持ち的にすっきりしないので、回路的に最上位の256KBを無効にできるように切り替えスイッチを増設しました。
| 512KB拡張RAM |
![]() |
| 768KB拡張RAM回路図 |
3.FT245高速通信カード
2023年10月23日のブログ「FT245通信カードの新基板の製作」https://flexonsbd.blogspot.com/2023/10/ft245.html
などで紹介したものです。オリジナルでは制御・データアドレスとして$FDFD,FEを使用しているのですが、このアドレスを他のカードが使用している可能性があるので$FD06,07に変更したものを作成しました。このアドレスはRS232Cカードが使用しているものなので、他のカードとバッティングすることはないと考えました。また、FT245カードとRS232Cカードは使用目的が同じなので同時使用することはないだろうと判断しました。
| FT245_R3 |
74LS04を1個増設しただけでアドレスを変更できました。
![]() |
| FT245_R3回路図 |
以上、自作のカードを少しでも使い易くするためにちょっとした改良を行ったという紹介でした。
時代錯誤ではありますが、折を見ながら昔のマイコン時代に使用していたGAME言語を6809に移植する試みを続けていまして、今までに2回報告しています。
・2021年5月19日のブログ「6800用のGAMEインタプリタとコンパイラを6809に移植」https://www.blogger.com/blog/post/edit/1662007451717538019/285975797531168690
・2019年5月8日のブログ「6802基板でGAME68コンパイラを走らせる」https://www.blogger.com/blog/post/edit/1662007451717538019/2314144451913456377
できる限りオリジナルから改変せずに自作の6802/6809両用カードにインタプリタとコンパイラを移植することを目指したので、既に他の方々が実践されているような高速化・高機能化とは無縁ですが、移植過程の経験とソースを得られることが目標でした。
上記2回の報告では、とりあえず動作したというレベルでしたので、何とか完成させたいと折を見ながら取り組んできましたが、ようやく完成と言ってもよいものができあがりましたので紹介するとともに作成したファイルを公開します。
作成に使用した自作マイコンですが、以前のブログで紹介したものと同じ6802/6809両用カードを使用しています。(見出しに画像を表示させるために以前と同じ画像を張り付けてあります。)
| 6802/6809両用カード |
まずインタプリタですが、ASCII誌に連載されたオリジナルのGAME3に作者の大西氏が行編集機能を追加されたものを使用しています。
オリジナルのソースに追加する必要があるのはI/O関係の1文字入力、1文字出力、ブレーク判定ルーチンのみで、変更点はRUB,DELコード、RAM末アドレスなどですが、これらについてはソースプログラムを添付しますのでそれを見ていただければ分かると思います。
前回のブログで紹介しましたが、ASCII誌に掲載された松島義明さんのH68/TR・TV用の「GAME68コンパイラ」を移植しました。(松島さんには申し訳ないのですが、名称をGAME3コンパイラに変更させていただきました。)
これはGAME3自身で記述されており、6809に移植しやすいということで使用しました。
基本的にはオリジナルのままで動作しますが、インタプリタ中のルーチンを使用していますので、上記のインタプリタとセットで使用します。
変更点は220行のモニタへのアドレス$F0B1と、オリジナルのままではコンパイル結果のバイナリを実行後に暴走しますので、80行の末尾にA:0)=$39を追加した2点のみです。
6800用GAME3インタプリタを元にして、6809用GAME9インタプリタを作成するわけですが、以前のブログで報告しましたように、基本的にはソースプログラムが公開されていますのでその6800の命令を6809の命令に置き換えるだけです。
置き換えに当たってはスタックポインタをインデックスポインタとして使用している箇所や比較命令CPXを1バイトスキップに利用している箇所に注意するだけで良いはずなのですが、何と終了判定にプログラムコード中の$00を利用している箇所があり、6800と6809では命令の長さが異なるために判定位置がずれてしまうことに気づかず、最後まで悩まされました。
以上に注意しながらインタプリタのソースを書き換えた結果、正常に動作させることができました。出来上がったものは基本的にただ6800の命令を6809の命令に置き換えただけですので、他の方々が移植されたものとは速度や機能の面で劣りますが、とにかく正常に動作するソースが作成できたということで良しとします。
続いて「GAME68コンパイラ」の移植に取り組みましたが、これも以前のブログで報告しましたが、まずランタイムルーチンのバイナリを逆アセンブルしてソースを起こし、それを6809の命令に書き換えました。
続いてコンパイラの移植ですが、まず、GAME自身で記述されているコンパイラのリスト中の、インタプリタ中のルーチンを呼んでいるアドレスを書き換え、次に、6800の命令コードを発行している箇所を見つけて6809の命令に置き換えました。 同じバイト数で置き換えられるものは単純に置き換えられるのですが、バイト数が変わる場合はそれに応じて、その周辺を書き換える必要がありました。
最後に、多少なりとも6809らしいコードを出力して欲しいということで、AccAとAccBの両方を使用している箇所をAccDに置き換える等を試みましたが、全てを置き換えることはできませんでした。
結果として作成したコンパイラですが、いくつかのサンプルプログラムを実行して正常にコンパイルできていることを確認し、最後にコンパイラ自身をコンパイルしてみました。
その結果、得られたバイナリが正常に動作しましたし、さらにそのバイナリでもう一度コンパイルしてみたところ、そのバイナリも正常に動作しました。
ただし、GAME9コンパイラ自身をコンパイルする過程では、最終行までコンパイルした後にハングアップしてしまいましたが、調べてみるとインタプリタに戻るアドレスが書き込まれていませんでしたので、手作業で該当の2個所に$0103を書き込むことで正常に動作するオブジェクトが得られました。
(この現象はGAME3でも同様でしたので、元のGAME68コンパイラに原因があるのではないかと思っていますが、コンパイルせずにそのまま使用した場合には正常に動作するので、原因については良く分かりません。)
以上により得られたファイルは次のようです。
[1]GAME3
・GAME3EX インタプリタ
・GAME3C コンパイラ(GAME言語で書かれたもの)
・GAME3CC コンパイラオブジェクト(GAME3Cを自身でコンパイルしたもの)
・RELSUB3 コンパイラ用ランタイムルーチン($2000-212Aだが移動可能)
コンパイル結果のオブジェクトの実行開始アドレスはランタイムルーチンの先頭アドレス+$012Bです。
[2]GAME9
・GAME9EX インタプリタ
・GAME9C コンパイラ(GAME言語で書かれたもの)
・GAME9CC コンパイラオブジェクト(GAME9Cを自身でコンパイルしたもの)
・RELSUB9 コンパイラ用ランタイムルーチン($2000-2106だが移動可能)
ランタイムルーチンがGAME3用よりも小さいのですが、操作を統一するためにコンパイル結果の実行開始アドレスをGAME3と同じランタイムルーチンの先頭アドレス+$012Bに揃えてあります。
コンパイラの動作速度を知るために、参考までに、インタプリタで300行弱のコンパイラプログラムを実行(コンパイル)した場合と、コンパイル済みのオブジェクトでコンパイルした時の時間を測ってみました。
(1)GAME3
・インタプリタでは、パス1終了までに4分30秒、パス2終了までに10分30秒
・コンパイラでは、パス1終了までに約11秒、パス2終了までに約29秒
(2)GAME9
・インタプリタでは、パス1終了までに4分11秒、パス2終了までに9分27秒
・コンパイラでは、パス1終了までに約11秒、パス2終了までに約25秒
先に作成したC版はサイズが12KB程度と大きく、そのために起動時や動作にやや時間がかかっていました。
その点が不満でしたのでアセンブラで書き直すことにしました。プログラム全体の構造はC版と同じで良いので、Cの命令をひとつひとつアセンブラの命令に置き換えていきました。CP/Mでのアセンブラ開発も初めてでしたので、命令表と首っ引きでしたが勘違いも多く、変なところで手間を食ったりしました。
結果、CP/M版もOS-9版もC版では12KBほどだったサイズが2KB程度と小さくなり、起動はもちろんですが動作も多少ですが速くなりました。
| OS-9メニュー画面 |
| CP/Mメニュー画面 |
メニュー3,4のディレクトリ表示のために、CP/M版ではディレクトリ表示ルーチンを作成してサブルーチンとして組み込みましたが、残念ながらOS-9版では今のところ、コンパクトなディレクトリ表示ルーチンをアセンブラで作成できていませんので、メニュー3,4は動作しません。メニュー3,4が必要な場合はC版を使用することになります。(以前、仮想ドライブ構築ソフトOs9DrvWin.exeをCで作成したときに、ディレクトリ表示部にはかなり複雑な処理が必要でしたので、これをアセンブラで作成できるかどうかは分かりません。)
これでF-BASIC版、FLEX9版、CP/M版、OS-9版の全てがアセンブラで作成できましたので、ファイル転送ソフトslwinftの制作はこれで一区切りをつけようと思います。あとはこれらをツールとしてプログラム開発に生かしていくつもりです。
参考までに、私のプログラム開発の手順を図で示します。
![]() |
プログラム開発の手順 |
これで一区切りとしますので、今までに制作したFM側のF-BASIC版、FLEX9版、CP/M版、OS-9版のslwinftとWindows側のslwinft245.exeをOneDriveに上げておきます。ディスクイメージ転送ソフトft245も同梱してあり、簡単な使い方の説明も付けてあります。
最後のCP/M版ができたので、FM-7で動作する全てのDOS(?)用の版(F-BASIC版、FLEX9版、OS-9版、CP/M版)が揃ったことになります。
CP/M版の動作画面です。FM-7上の富士通版CP/M-80上で動作しています。
| CP/M版slwinft |
しかし残念ながら、メニュー3,4のディレクトリ表示は未実装です。BDS-Cで書いたのですが、標準関数のexec()などではビルトインコマンドのdirは動作しないのです。ということで、dirコマンドに相当するものを作成する必要がありますが、それには時間がかかりそうです。
また、現在のところ、FM77AV2に装着してあるZ80Hカード(IDATEN)上のCP/Mでは何故か正常に動作していません。(ソフトは正常に動作しているように見えるのですが、実際にはファイルが転送されないのです...)AV2でもF-BASIC版など他の版では正常に転送できていますので、ハードには問題はないと思うのですが、原因はまだ分かっていません。
蛇足ですが、純正のCP/M-80カードは大切に保管してあるので、普段は自作のカードを使用しています。
| 自作CP/M-80カード |
完成度については、F-BASIC版>FLEX9版>OS-9版>CP/M版という感じで、特にCP/M版についてはBDS-Cを使うのは初めてということもあり、試行錯誤の連続でした。現在のところ、メニューの3,4は実行できませんし、動作速度もアセンブラで書いたF-BASIC版やFLEX9版より遅いようです。
しかし、今まではディスクイメージ全体を転送するソフトしかなく、2Dディスク一枚の転送に1分ほどの時間がかかっていたので、Windows上のエディタでプログラムソースを作成し、それを各DOSに転送してアセンブルやコンパイルするという手順の繰り返しが面倒でしたが、これらのファイル転送ソフトのおかげで大幅に時間が短縮できるようになりました。これらのソフトの開発中も、Windowsー>FM-7方向の転送部分をまず作成し、それを繰り返し使いながらソフト全体を仕上げていくことができました。(CP/Mに標準添付のエディタEDを流石に使う気にはなれないので、制作途中の手直しは全てWindows上のエディタで行うという開発スタイルです。)
完成度の低いOS-9版とCP/M版についてはこれからも改善していくことになると思いますが、とりあえず一段落したということにして作成した4種の版をまとめてOneDriveに上げておきます。CP/M版以外の版も細かい修正を重ねていますので、ここに上げたものが最新版となります。また、ディスクイメージ転送ソフトも含まれています。
| F-BASIC版のSLWINFT |
| OS-9版のslwinft |
| FLEX9版のSLWINFT |
| Windows側のslwinft245 |
| OS-9側のslwinftos9のメニュー |
| メニュー1の実行例 |