ASSIST09にLoad, Saveコマンドを追加

WindowsへのLoad，Saveコマンドを追加しました

ASSIST09のLoad，Punchコマンドはテープが対象なので、実用にはなりません。
私はFLEXを常用しているので、モニターはメモリ内容を変更、確認する場合ぐらいにしか利用していなかったのですが、よく考えてみると、ファイルの単純なLoad，SaveぐらいならわざわざOSを起動しなくてもモニターのみで良いのではないかと思えてきました。


ASSIST09はコマンドの追加が簡単にできますので、Windows上にファイルをモトローラのS-formatでSave，Loadできる拡張コマンドを作ってみました。

動作のイメージ

ASSIST09側：LOAD, SAVE（拡張コマンドとして内蔵）
Windows側 ：slwin.exe（あらかじめ起動しておく）

コマンド入力の様子

書式

Windows側で動作するプログラム

Saveコマンド：SAVE（ret)
その後、ファイル名、先頭アドレス、終了アドレス、実行アドレスの順に入力すると確認を求めてきますのでYを入力するとメモリの指定範囲の内容がモトローラのS-formatで保存されます。

Loadコマンド：LOAD（ret）
その後、ファイル名を入力すると保存されているファイルがもとの位置に読み込まれ、実行開始アドレスを表示して終了します。




Windows側ではコマンドプロンプト画面を開いておき、ファイルを保存したいフォルダに移動して、slwin.exeを起動します。起動オプションとしてポート番号、ボーレートと保存フォルダが指定できますので、

slwin p=4 b=38400 path

のように指定します。省略時は、ポート番号は1、ボーレートは38400boud、保存フォルダはカレントディレクトリとなります。
（slwin.exeをGitHubに上げておきます。）　GitHubへのファイルの追加の仕方が分からない。。。分かりましたらアップしておきます。
（5月29日追記）追加方法が結局分からなかったので、とりあえずMicrosoftのOneDriveに上げておきます。

ファイルの書式変換

モトローラのS-formatは実行アドレスが保存できるので便利なのですが、他の書式に変換したい場合もあると思います。私も、例えばROMライターにデータを送る際にはインテルのhex-formatを用いています。
私は自作のS-format, Hex-format, Binary相互間の書式変換ができるソフトCvtMotHexBin.exeを使っています。
（CvtMotHexBin.exeもGitHubに上げておきます。）　GitHubへのファイルの追加の仕方が分からない。。。分かりましたらアップしておきます。
（5月29日追記）追加方法が結局分からなかったので、とりあえずMicrosoftのOneDriveに上げておきます。
（5月31日追記）不具合のあるバージョンを上げてしまっていましたので、修正版に差し替えました。

接続ケーブルを変えました

接続ケーブルを変換基板から変換ケーブルに変えました

今まで使用していたケーブルは有り合わせのもので、

使用していた変換基板

MAX232使用のTTL-シリアル変換基板プラスUSB-シリアル変換ケーブルと、秋月電子のAE-UM232Rに自作基板を付けたものの2本でした。

使えた変換ケーブル

どうも使いにくいので、ヤフオクに出ていたTTL-USB変換ケーブルを使ってみました。（送料込み2本でたった千円ほど...）

このシングルボードコンピュータで使用しているプログラムでは、RTS信号によるハードウェア制御をしているので、巷で良く見る、RTS信号ではなくDTR信号がでているケーブルは使えないはずですが、このケーブルはすんなりと使えました。
（使えたので、RTS信号が出ているのかどうかは確かめていません。。。手抜きですね）
これで、基板周りがすっきりしました。

MicroCを使う（その１）

MicroCのソース

FLEX9にはその昔、太田昌孝さんが作られた有名なMicroCという整数型のCコンパイラがありました。商品としても売られていた記憶があります。
数年前に「C言語と周辺制御」（新津靖、池上晧三　工学社）という、MicroCを使用して制御をするという本を入手してから、ぜひ使ってみたいと思っていました。

そのソースとそれ用のアセンブラが竹岡さんのサイトからダウンロードできます。
しかし、これはBSD用ですので、私が常用しているLinuxではそのままではビルドできません。

MicroCのソースをLinuxでビルドする

全体の流れ

(1)gccでmc.cをコンパイルー＞mc（Linux上で動作するクロスコンパイラ）

(2)mcでmc2.cをコンパイル－＞c.out（クロスコンパイラで作成したアセンブルリスト）

(3)as09でc.txtをアセンブルー＞mc2.o（モトローラS形式のオブジェクト）

(4)mot2binでバイナリ形式にー＞mc09に名称変更し、先頭の$00~$FFは不要なので削除する（バイナリ形式の実行ファイル）

(1) mcの作成

stdio.hの宣言とバッティングする2つのファイル名を変更する。

　　getline() -> getline2()

　　index() -> index2()

この変更によって、make中の gcc mc.c -O mc で mcが作られるが、保存されない。

続いて、mc.c 中の printf( を全て fprintf(obuf, に変更すると、ファイル c.out に保存される。

最後に、作成したmc09とC.TXT、そしてライブラリc.txt, stdio.txt, stdio2.txt, alloc.txt, fileio.txt, fileio2.txt. scanf.txt, string.txt、そしてユーティリティuf.cをFLEXへ転送する。
（2014年当時のメモ書きを元に書いていますが、最近のUbuntu 16ではindex()はバッティングしないなど、違いがあるかもしれません...）

mc09を使う

(1)ソース作成上の注意
標準で、stdio.txt, alloc.txtをインクルードしなければならない。（ファイル名は大文字で）
また、アセンブラASMBではTABコードは別のものとみなされてしまうので、Spaceに変換しておく。さらに、行末の$0D,$0Aも$0Dのみに変換しておく。
(2)ビルド
mc09 -O1.C.OUT file.c でドライブ1にC.OUTが作られる。（C.OUT名は変更できない）
(3)アセンブル
あらかじめドライブ1にC.TXTを入れておく。
ASMB C.TXT +YLS でC.TXTのアセンブル中にC.OUTが読み込まれてアセンブルされC.binが作られる。
(4)実行
得られるC.binは$100からにロードされ、$100から実行されるファイルなので、そのまま実行できる。

基板は完成したと思ったのに

最初の基板は十分検討していなかった部分もあり、特に6802SBD基板は修正箇所が多かったのですが、今度はしっかりとテストしてから発注したので大丈夫と思っていたのですが、やってしまいました。。。

6802SBD V2基板を完成させてFLEX68を動かしながらあれこれ試していたところ、
GAMEIIIで変数がA~Mの時のみ結果がおかしいことに気づきました。
GAMEIIIのソースリストと何度も見比べてみましたが間違いはありません。

ソフトではなくハードに問題がありそうだということで、モニタに戻ってメモリーの書き込みテストをしてみると、$00~$1Fのみ正常に書き込みできません。
自作モニタでもMIKBUG2.0でも同様でした。

このエリアは内蔵RAMのうちのバッテリバックアップ可能なRAMです。
6802のREはGNDに落としてあるので、内蔵RAMでなく外部RAMがアクティブになっているはずです。でも明らかに内蔵RAMが悪さをしているような。うーん、理解できない。

試しに、未接続だったVccStanbyをVCCに接続すると正常に読み書きできるではありませんか。（datasheetにはそんなことは書いてないぞ！）

ということで、痛恨のジャンパー配線が1本必要となってしまいました。

FLEXシステムの作成方法（その１）

（１）FLEX.CORを入手する
「SWTPC emulator」でネット検索して「Evenson Consulting ServicesのSWTPC 6800/6809 Emulator」を探し、その中のDownloads/UpgradesタブからComplete Setup current versionをクリックするとSWTPCemuSetup.exeがダウンロードできます。
適当なコンピュータで実行するとSWTPCemulatorがインストールされ、その中のDisksフォルダ中にFLEX6800,FLEX6809の2つが作られ、それぞれ100近いDSKファイルが入っています。
それらのDSKファイルをバイナリエディタで開いてDirectoryを見ると、FLEXx.SYSやFLEXx.CORが見つかります。（6809の場合はFLEX9.SYS,6800ではFLEX2.SYS)

　(6月21日訂正）ご指摘を受けましたので、上記の説明文を次のように訂正します。
Downloads/UpgradesタブからFULL KitをクリックするとSWTPCFULL.zipがダウンロードできます。
このzipファイルを解凍するとSWTPCFULLフォルダ中にSWTPCemuInstallX.exeがありますので、これを実行するとProgram Filesフォルダ中にEvenson Consulting Services\SWTPCemuフォルダが作られます。この中のDisksフォルダ中にDSKファイルがあります。
（2019年7月1日訂正）SWTPCFULL.zipに関する質問がありましたので、Evenson Consulting Servicesのサイトを見ましたら、ファイルの置き場所が変わっていました。
下の質問の回答中に置き場所を書きましたのでそちらをご覧ください。

（２）Driver、Console I/Oルーチンを作る
この2つのルーチンは各自のシステムに合わせて作成しなければなりません。
DriverルーチンはFLEX用Virtual Driverの作り方（4月21日）で説明しましたコマンド応答に合わせて作る必要があります。
私が使用している、この6809シングルボード用のDriverルーチンとConsole I/OルーチンをGitHubに上げておきます。

（３）FLEX.SYSを作る
最後に、CORファイルとDriver、Console I/OルーチンをFLEXのAppendコマンドでつなげば良いのですが、そもそもFLEXが動いていなければAppendコマンドは使えません。

バイナリファイルの模式図

どうすれば良いかですが、そもそもAppendコマンドは、COR, Driver, Consoleの3つのファイルのセクターを連続させているだけなので、直接、バイナリエディタでくっつけてしまえば良いのです。
エディタ上でFLEX.COR，Driver.bin，Console.binを並べて各セクターの先頭4バイトのレコード番号値を直接書き換えます。
そして、FLEX.CORの先頭セクター、最終セクター、セクター数をDirectoryに書き、SIRの情報もそれに合わせて書き換えます。




私が使用しているDriver，ConsoleルーチンをGitHubに上げておきます。

シングルボードコンピュータとFLEXシステムの詳細

［１］シングルボードコンピュータの仕様

（１）メモリーマップ
　RAMを64KB実装し、その上にMonitorとして4KBのROM,I/Oエリアとして128bytesを重ねています。
FLEXシステムは6809用ではC700からDFFFに、6800用ではA700からBFFFに位置しています。

メモリマップ

（２）I/O
　I/OとしてはACIA(6850)のみですので、シリアルインターフェースが2組ということになります。それぞれのアドレスは$F0BC,BDと$F0CC,CDですが、アドレスA1をデコードしていないので、＄F0BE,BFと＄F0CE,CFにゴーストが現れています。
6850-1はコンソールI/Oに、6850-2はWindows上の仮想ディスクとの通信に使うことを想定しています。
通信速度は、システムクロックが1MHz（原発振は4MHz）では19200baud、2MHz（同８MHｚ）では38400baudです。システムクロックの4倍の原発振を13分周して6850へ供給しています。

（３）拡張ROM-1,-2
　拡張ROMはI/Oがあるために連続していませんが、6809ではASSIST09の拡張コマンドFillとTransferコマンド（インターフェース誌1982年4月号より）、そしてFLEX起動コマンドを入れています。6802ではVTL等のアプリケーション用のコンソールI/OプログラムとFLEX起動コマンドを入れています。

［２］FLEXシステムの詳細

（１）FLEXシステムの構成
FLEXシステムはFLEX.CORとDISK DRIVERとCONSOLE I/Oからなり、ユーザが作成する必要があるのはDISK DRIVERとCONSOLE I/Oの２つです。
（6800用ではCONSOLE I/OがDISK DRIVERの中に含まれる形になっています。）

（２）DISK DRIVER
DISK DRIVERは基本的にFDC(フロッピーディスクコントローラ）FD1791を使用したFDDシステムを使用する前提になっていますが、この仕様に合わせて仮想ドライブをアクセスするルーチンが必要です。

（３）CONSOLE I/O
CONSOLE I/Oは基本的にACIAによるシリアルインターフェースを使用する前提になっていますので、そのままACIAによるI/Oルーチンを作成すれば良いことになります。

（４）DISKの特徴
FLEXシステムにはFAT（ファイルアロケーションテーブル）のようなDISK全体を管理する部分はなく、全てのセクターが繋がったチェーン構造をしています。
各セクターの最初の4バイトが、次のレコードのトラック番号（1byte）、セクター番号（1byte）、レコード番号（2byte）を表しており、セクターを読むと、次に読むべきセクターが分かるようになっています。レコードの最終セクターはトラック番号とセクター番号が00になっています。
レコードの最初のトラック番号、セクター番号はディレクトリに書かれているので、ディレクトリからファイル名を検索し、見つけたらそのトラック番号とセクター番号のセクターから読み始めれば良いわけです。
このような構造から、複数のセクターをまとめて読むことができず、FLEXのDISKアクセスは遅いという評判につながったわけですが、仮想ドライブという面からみると、DISKの容量やトラック数、セクター数の制限がなく、かえって柔軟なシステムと言えるように思います。（ただ一つの制限はセクター容量が256bytesでなければならないということです。）

（５）DISKの構成
　トラック00
　　セクター01, 02　Boot Loader
　　セクター03　　　SIR（System Information Record)
                              　ディスク名、最大トラック、セクターや残りセクター数など記録
　　セクター05　　　Directory（最終セクターまで）
　トラック01　　　　Data（最終トラックまで）

SIR（セクター03）

Directory（セクター05~）

（６）データファイルの保存形式
テキストファイルは基本的にそのままの形でディスクに保存されますが、複数のスペースが続く場合、$09＋スペース数という形で圧縮されて保存されます。読み出し時には、それが展開されます。
バイナリファイルの場合はちょっと面倒です。べたのバイナリファイルは存在せず、パケット形式に変換されて保存されます。FLEXシステムデータ自身も同様です。
パケット形式　データ：$02＋スタートアドレス(2bytes)＋データ数(1byte )＋データ列
　　　　　　　　　　　の繰り返し（データ数の標準値は$C4）
　　　　　　　実行アドレス：$16＋実行アドレス(2bytes)
従って、Windowsで作成したバイナリファイルをFLEXのDSKファイルに保存するためには、あらかじめパケット形式に変換するか、あるいはHexファイルにしてFLEXに送り、FLEX上でHex－＞Binary変換をしなければなりません。

63C09Pを購入したつもりが...

eBayでHD63C09PとHD63B50Pを購入しました。
HD63B50Pは比較的早く届き、ほとんど発熱もせず2MHzで動作しましたので、間違いない品だと思いますが、HD63C09Pは1ヶ月過ぎても届かず、催促した挙句、40日を過ぎてようやく届いたと思ったら、表面がザラザラでいかにも怪しげで、案の定、シングルボードコンピュータに装着しても動作しません。6809EP用のアダプターに装着してセットすると動作するではありませんか。

表面の質感も悪く、刻印も薄い

偽造品が出回っているという話は以前から聞いていましたので、ショップの商品見本の写真を見て、これならと思って注文したのに、写真とは大違い。
ショップに交換を要求しましたが、今のところ返事なし。。。

以前、全くの不動品をつかまされたこともあったので、今回はEPとして動作するだけ増しかも。。。

（'18.5.7追記）
ショップにクレームを入れたところ、届いたICを破壊してその写真を送れば返金するがという返事が来たので、応じることにしました。

EPとしては動作するので、破壊するのにはためらいもありましたが、表面の質感も悪いし、何よりも偽造品を承知で使用し続けるのは気持ちが良くないですよね。