2024年3月25日月曜日

FM-7/77用の自作基板(RS232Cカード、FT245通信カード、1024KB拡張RAMカード)のプチ改良

 FM-7/77用の自作基板3枚を少しですが改良しました

改良版を製作したのは次の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回路図


使用したケーブルは以下のようなものです。ピン配置は1番ピンから順にGND, RTS, VCC, RXD, TXD, CTSになっていますが、VCCは接続しないのでピンを抜いてあります。


使用した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

ちなみにこの48ピンコネクタは、知人が32ピンのコネクタ2個からニコイチで作成されたものをいただいて使用していますが、全く不都合はなく使用できています。


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回路図

以上、自作のカードを少しでも使い易くするためにちょっとした改良を行ったという紹介でした。


2024年3月24日日曜日

6800用GAMEインタプリタとコンパイラの6809への移植がようやく完成

 6800用のGAMEインタプリタとコンパイラの6809への移植がようやく完成しました

時代錯誤ではありますが、折を見ながら昔のマイコン時代に使用していた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両用カード


1.GAME3インタプリタ

まずインタプリタですが、ASCII誌に連載されたオリジナルのGAME3に作者の大西氏が行編集機能を追加されたものを使用しています。

オリジナルのソースに追加する必要があるのはI/O関係の1文字入力、1文字出力、ブレーク判定ルーチンのみで、変更点はRUB,DELコード、RAM末アドレスなどですが、これらについてはソースプログラムを添付しますのでそれを見ていただければ分かると思います。


2.GAME3コンパイラ

前回のブログで紹介しましたが、ASCII誌に掲載された松島義明さんのH68/TR・TV用の「GAME68コンパイラ」を移植しました。(松島さんには申し訳ないのですが、名称をGAME3コンパイラに変更させていただきました。)

これはGAME3自身で記述されており、6809に移植しやすいということで使用しました。

基本的にはオリジナルのままで動作しますが、インタプリタ中のルーチンを使用していますので、上記のインタプリタとセットで使用します。

変更点は220行のモニタへのアドレス$F0B1と、オリジナルのままではコンパイル結果のバイナリを実行後に暴走しますので、80行の末尾にA:0)=$39を追加した2点のみです。


3.GAME9インタプリタ

6800用GAME3インタプリタを元にして、6809用GAME9インタプリタを作成するわけですが、以前のブログで報告しましたように、基本的にはソースプログラムが公開されていますのでその6800の命令を6809の命令に置き換えるだけです。

置き換えに当たってはスタックポインタをインデックスポインタとして使用している箇所や比較命令CPXを1バイトスキップに利用している箇所に注意するだけで良いはずなのですが、何と終了判定にプログラムコード中の$00を利用している箇所があり、6800と6809では命令の長さが異なるために判定位置がずれてしまうことに気づかず、最後まで悩まされました。

以上に注意しながらインタプリタのソースを書き換えた結果、正常に動作させることができました。出来上がったものは基本的にただ6800の命令を6809の命令に置き換えただけですので、他の方々が移植されたものとは速度や機能の面で劣りますが、とにかく正常に動作するソースが作成できたということで良しとします。


4.GAME9コンパイラ

続いて「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秒

という結果でしたので、インタプリタとコンパイラの実行速度比はGAME3でおよそ22倍、GAME9でおよそ23倍となりました。

作成したGAME9インタプリタとコンパイラをGAME3のそれと一緒にOneDriveに上げておきます。(GAME3のコンパイラについては、以前のブログで公開する際に作者の了解を得てあります。)