２０１２．３．３１
前へ
次へ
ホームページトップへ戻る

復活！ＣＰ／Ｍ　ワンボードマイコンでＣＰ／Ｍを！
ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！

［第７７回］

●ファンクションコール０ＢＨのテスト

ＢＩＯＳプログラムを修正しましたので、あらためてファンクションコール０ＢＨのテストをしてみます。
［第６８回］のテストプログラムを少し変更しました。
下は変更したテストプログラム（ＦＮＣ０ＢＴ５．ＴＸＴ）です。
表示のためのサブルーチンは変更していませんから省略してあります。

; BDOS function0B test 5
;2012/3/28
;
	ORG $8100
	FCALL=$8005
;
LOOP:LD C,0B
	CALL FCALL
	PUSH AF
	CALL B2HEXDP
	POP AF
	OR A
	JP NZ,KEYIN
NEXT:CALL SPDP
	JP LOOP
KEYIN:LD C,01
	CALL FCALL
	PUSH AF
	CALL B2HEXDP
	POP AF
	CP 01;^A
	JP Z,STOP
	CP 1A;^Z
	RET Z
	JP NEXT
STOP:LD A,3F;?
	CALL ADP
	JP KEYIN
;

［第６８回］のテストプログラムでは動作確認のためＣＨＡＲＢＵＦを参照していましたが、その確認は済みましたので、その部分は外しました。
また新しく［Ｃｔｒｌ］［ａ］を入力したら、そこでポーズしてコンソール入力を受け付ける、という部分を追加しました。

こちらはＺＡＳＭ．ＣＯＭでアセンブルして作成されたアセンブルリストです。

2012/3/29  13:40  fnc0bt5.txt
END=8194
              ; BDOS function0B test 5
              ;2012/3/28
              ;
              	ORG $8100
              	FCALL=$8005
              ;
8100 0E0B     LOOP:LD C,0B
8102 CD0580   	CALL FCALL
8105 F5       	PUSH AF
8106 CD5981   	CALL B2HEXDP
8109 F1       	POP AF
810A B7       	OR A
810B C21481   	JP NZ,KEYIN
810E CD3B81   NEXT:CALL SPDP
8111 C30081   	JP LOOP
8114 0E01     KEYIN:LD C,01
8116 CD0580   	CALL FCALL
8119 F5       	PUSH AF
811A CD5981   	CALL B2HEXDP
811D F1       	POP AF
811E FE01     	CP 01;^A
8120 CA2981   	JP Z,STOP
8123 FE1A     	CP 1A;^Z
8125 C8       	RET Z
8126 C30E81   	JP NEXT
8129 3E3F     STOP:LD A,3F;?
812B CD3D81   	CALL ADP
812E C31481   	JP KEYIN
              ;

●ＣＰ／Ｍとテストプログラムのロード

いつものようにログファイルで説明します。
前回ＢＩＯＳを修正して作成したＣＰＭ２２Ｊ．ＢＩＮと、テストプログラムＦＮＣ０ＢＴ５．ＢＩＮをＮＤ８０ＺⅢにロードしました。
そのあとＪＰ　Ｄ２３３でＣＰ／Ｍを起動しました。

logfile nd80zlog\03291340.txt open

ＮＤ８０ＺⅢに接続しました
0001 0000 - z
1000 00C3 - 
*** nd80z3 basic ****
>/ld cpm22j.bin,bc00
loading CPM22J.BIN ...1749(5961)bytes loaded,from BC00 to D348
>/ld fnc0bt5.bin,8100
loading FNC0BT5.BIN ...0095(149)bytes loaded,from 8100 to 8194
>jp d233
a>

テストプログラムをＦＮＣ０ＢＴ５．ＣＯＭの名前でＳＡＶＥしたあと、ＦＮＣ０ＢＴ５［Ｅｎｔｅｒ］と入力して、テストプログラムを実行しました。

a>save 1 fnc0bt5.com
a>fnc0bt5
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 01a61 00 00 00 00 00 01a61 00 01a61 00 00 00 00 00 00 00 00 00 00 00 00 0
0 00 00 00 00 00 00 01b62 00 00 00 01b62 01b62 01b62 01b62 00 01b62 01b62 01b62 
01b62 01b62 01b62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c63 01c63 00
 00 00 01c63 01c63 01c63 01c63 01c63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
0 00 00 00 00 00 00 00 00 00 0101?d64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01     
09 01   09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
        09 00 00 01     09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >
>

テストプログラムがスタートすると、ファンクション０ＢＨが繰り返しコールされ、その戻り値（コンソール入力無しのときは００）が連続して表示されていきます。
キー［ａ］を押すと、戻り値が０１（キー入力有り）と表示され、キー入力された文字ａと、その文字コード６１Ｈが表示されました。
同じようにして、ｂ（６２Ｈ）、ｃ（６３Ｈ）を入力してみました。

上から６行目のところで［Ｃｔｒｌ］［ａ］を入力しています。
さきほどのアセンブルリストのアドレス８１１ＥＨのところです。
［Ｃｔｒｌ］［ａ］が入力されると、？を表示してコンソール入力を待ちます。
ここでは［ｄ］を入力しました。
入力したｄの文字コード６４が表示されたあと、再びファンクション０ＢＨの戻り値が連続して表示されています。

そのあとは何回か［Ｔａｂ］キーを入力しました。
ＴＡＢが実行されて、カーソルが移動したあとＴＡＢの文字コード０９が表示されています。

最後に［Ｃｔｒｌ］［ｓ］を入力してポーズしたあと、［Ｃｔｒｌ］［ｄ］を入力したところブレイクしてＺＢ３ＢＡＳＩＣに戻って＞が表示されました。
［Ｃｔｒｌ］［Ｄ］（本来は［Ｃｔｒｌ］［Ｃ］）を入力するとシステムがリブートされるのですが、今はシステムを開発中なので、ＺＢ３ＢＡＳＩＣに戻るようにしてあります。

どうやらファンクションコール０ＢＨは正しく機能しているようです。

もう一度ＣＰ／Ｍに戻って、今度は［Ｃｔｒｌ］［ｚ］の入力を試してみることにしました。

>jp d233

a>fnc0bt5
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a61 00 00 01a61 00 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 01b62 01b62 00 01b62 00 01b62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 01c63 01c63 01c63 00 00 00 00 01c63 01c63 01c63 00 00 00 00 00 00 00 00 00 00 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 0101?d64 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 011A
a>

ＪＰ　Ｄ２３３［Ｅｎｔｅｒ］でＣＰ／Ｍにエントリしました。
さきほどと同じように、ＦＮＣ０ＢＴ５［Ｅｎｔｅｒ］でテストプログラムを開始し、［ａ］、［ｂ］、［ｃ］と順に入力したあと、［Ｃｔｒｌ］［ａ］を入力しました。
ポーズしたあと［ｄ］を入力すると、再び表示が連続して行なわれました。
今回は最後に［Ｃｔｒｌ］［ｚ］（コード１Ａ）を入力したところ、そこでテストプログラムが終了してシステムに戻りました。
うむ。
やっと。完璧です。

●ＣＫＣＯＮＳＯＬルーチンのテスト

［第７５回］で説明しましたように、ＣＫＣＯＮＳＯＬルーチン（コンソールステータスチェック）は、ファンクションコール０ＢＨだけではなくて、コンソールなどへの文字出力ルーチンでもコールされていることがわかりました。

ファンクションコール０ＢＨについての今までのテストプログラムでは、コンソールステータスを取得することによって、他の処理の実行中にキー入力を受け付ける目的でテストをしてきました。
そのついでにＣｔｒｌ－Ｓ、Ｃｔｒｌ－Ｄによるプログラムの強制終了の機能についても試したのでした。

しかし、ＣＫＣＯＮＳＯＬルーチンが文字出力ルーチンでもコールされているということならば、連続してコンソール出力を行なうようなプログラムで、その実行を強制終了させたい（その他のコンソール入力は必要ない）、というときは、わざわざファンクションコール０ＢＨを使わなくても、表示中にＣｔｒｌ－Ｓ、Ｃｔｒｌ－Ｄを入力すれば、強制終了させることができるはずです。

本当にそうなのか。
これも試してみることにしました。

下がそのためのテストプログラムです。
ＦＵＮＣ０ＢＴ６．ＴＸＴです。
今回も表示のためのサブルーチンは省略してあります（表示のためのサブルーチンは今までのテストプログラムと同じものを使っています）。

; BDOS function0B test 6
;2012/3/29
;
	ORG $8100
	FCALL=$8005
;
	LD A,00
LOOP:PUSH AF
	CALL B2HEXDP
	POP AF
	INC A
	JP LOOP
;

Ａレジスタの値を＋１しながら、それを１６進数で表示するというだけのプログラムです。
ここでは省略していますが、Ａレジスタの値を１６進数２桁で表示するＢ２ＨＥＸＤＰサブルーチンでは、ファンクションコール０２（コンソール出力）が使われています。

あ。
今回はファンクションコール０ＢＨは使っていませんから、ＦＮＣ０ＢＴ６というファイル名はミスマッチでした。

こちらはＺＡＳＭ．ＣＯＭでアセンブルして作成されたアセンブルリストです。

2012/3/29  14:11  fnc0bt6.txt
END=816E
              ; BDOS function0B test 6
              ;2012/3/29
              ;
              	ORG $8100
              	FCALL=$8005
              ;
8100 3E00     	LD A,00
8102 F5       LOOP:PUSH AF
8103 CD3381   	CALL B2HEXDP
8106 F1       	POP AF
8107 3C       	INC A
8108 C30281   	JP LOOP
              ;

下はＦＮＣ０ＢＴ６．ＢＩＮをＮＤ８０ＺⅢにロードして、ＣＰ／Ｍで実行してみたときのログファイルです。

logfile nd80zlog\03291411.txt open

ＮＤ８０ＺⅢに接続しました
0001 0000 - z
1000 00C3 - 
*** nd80z3 basic ****
>/ld fnc0bt6.bin,8100
loading FNC0BT6.BIN ...006f(111)bytes loaded,from 8100 to 816E
>jp d233

a>save 1 fnc0bt6.com
a>fnc0bt6
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F2021222324252627
28292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F
505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F7071727374757677
78797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9F
A0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7
C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF000102030405060708090A0B0C0D0E0F1011121314151617
18191A1B1C1D1E>

ERR: 1 
>
>0000 00C3 - 
リモート接続を終了しました
logfile closed at Thu Mar 29 14:12:46 2012

ＪＰ　Ｄ２３３［Ｅｎｔｅｒ］でＣＰ／Ｍを起動して、ＦＮＣ０ＢＴ６．ＣＯＭというファイル名でＲＡＭディスクにセーブしたあと、ＦＮＣ０ＢＴ６［Ｅｎｔｅｒ］と入力して、テストプログラムを実行しました。

００、０１、０２…と１６進数２桁の数値がカウントアップされながら連続して表示されています。
最後のところで＞が表示されています。
表示中に［Ｃｔｒｌ］［ｓ］を入力したところ表示が中断しましたから、そこで［Ｃｔｒｌ］［ｄ］を入力しました。
その結果システムブレイクがおきて、ＺＢ３ＢＡＳＩＣに戻り、そこで＞が表示されたことを示しています。
おお。
やはり、そういうことでした。

●ＣＰ／Ｍでのブレイクの方法

ＣＰ／Ｍでは本当の意味でのシステムブレイクの手段としては、この「Ｃｔｒｌ－ＳでポーズさせてからＣｔｒｌ－Ｄ（本来はＣｔｒｌ－Ｃ）を入力」を使うようです。

ちなみにＷｉｎｄｏｗｓの１６ビットアプリケーションでもよく使われるＣｔｒｌ－Ｃによるブレイクは、あらかじめユーザープログラムの中でそれをチェックしてブレイクするようにしておかなければ、機能してくれません。
Ｃｔｒｌ－Ｃはシステムに組み込まれた機能ではなくて、そのようにプログラムしようよ、というプログラマの「お約束」ということのようです。
その意味では、今までのテストプログラムの中でときどき使用しております［Ｃｔｒｌ］［ｚ］によるブレイクと同じ扱いであると言えるでしょう。

何かでコントロールが利かなくなって画面に文字が連続して表示されて、それが止まらなくなったような場合、まずはＣｔｒｌ－Ｃを試しますが、それを受け付けてくれないこともよくあります。
そんなときはこの「Ｃｔｒｌ－ＳでポーズさせてからＣｔｒｌ－Ｄ（本来はＣｔｒｌ－Ｃ）を入力」の出番になります。
もっとも画面表示がフリーズしてしまい、プログラムのほかのところでループからぬけだせなくなってしまったような場合には、Ｃｔｒｌ－Ｓも受け付けてはくれません。

その場合の最後の手段は「リセットスイッチを押す」ことしかありません。

●Ｗｉｎｄｏｗｓでのブレイク方法

このあたりの事情はＷｉｎｄｏｗｓの１６ビットアプリケーションでも、ほぼ同じです。
Ｗｉｎｄｏｗｓの場合にはＣｔｒｌ－Ｓではなくて、［Ｐａｕｓｅ］キーを使うようです（［第７０回］参照）。
それでもブレイクしない場合には、コマンドプロンプト画面右上の［×］をクリックして強制終了します。
それでもだめ、というような事態はさすがにＷｉｎｄｏｗｓ７ではほとんど経験していませんが、「何をやっても駄目」という完全フリーズ状態はＷｉｎｄｏｗｓ９５やＷｉｎｄｏｗｓ９８ではよく経験しました。

あ。
Ｗｉｎｄｏｗｓ９５やＷｉｎｄｏｗｓ９８の場合の完全フリーズは１６ビットアプリケーションを実行したことが原因とは限らず、いろいろな理由でごく日常茶飯事のことでした（おお、恐ろしい）。
Ｗｉｎｄｏｗｓ９８ＳＥでは滅多におきなくなりましたが、それでも時たまつむじを曲げてだんまりを決め込んでくれることがあります。
こうなると、ある程度のリスクは承知のうえで、リセットスイッチを押すことになります。

Ｗｉｎｄｏｗｓ７の場合には、システムによるガードがかなり効いていて、そのような心配はほとんどなくなったようです。
しかしガードが効いているということは、ちょうど孫悟空がお釈迦様の手のひらから外に飛び出せなかったのと同じような状態である、と言えます。
普通のユーザーにとっては、それは快適な環境を意味しますが、プログラマにとっては、その手のひらから外に飛び出したいときも多々あるわけで、それが許されないということは、なんとも使いにくい場合が出てきます。

私がいまだにＷｉｎｄｏｗｓ９８（ＳＥ）を手放せない、というのはそういう理由からなのです。
あ。
クルマや家電品でもそうですが、昔はちょいと器用な人でしたら、中を明けて自分で部品を交換して直してしまう、などということもできたように思います。
今では、そのようなことはほぼ不可能になってしまいました。
高額の修理費をかけてメーカーに直してもらうか、それともあきらめて捨ててしまうか、の二者択一です。
技術革新は、その一方でＤＩＹ派から、やる気を奪ってしまいます（なんとも困ったものです）。

●メールの続きです

［第７０回］で、Ｙ様からいただいたメールをご紹介いたしましたが、その後にまた続きのメールをいただきました。
Ｙ様は当時の業界の事情に精通してみえて、とても詳しいことをご存知です。
私ひとりが読ませていただくだけでは勿体無いと思いますので、Ｙ様からご了解をいただいて、皆様にもお読みいただくことにいたします。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

コンピュータの操作方法とキーボード構成は密接につながっていることが多いです。

LISPマシンなどの一部の特殊なコンピュータには専用のキーボードがあります。

操作上コントロールキーを多用したUNIXマシン専用端末のキーボードでは、コントロールキーがシフトキーと同じ大きさでした。

通常の文字コードには含まれない「Break」キーなどの特殊キーも存在していました。

初期のBASICマシンには「Break」キーがありました。

PET２００１には「RUN STOP」キー
TRS－８０には「Break」キー
そしてPC－８００１には「STOP」キー。これはPC－９８０１まで継承されました。

上記三機種にはマイクロソフトBASICが搭載されたいたので中身はほぼ同じです。

これらの「Break」キーは、「Ctrl-C」のコードを発生していた可能性がありますが、よくわかりません。

MS－DOS時代になると「Pouse」「Break」キーになりました。

世代の進化により特殊キーや、コントロールコード、ショートカットの意味や機能、使い方が大きく変わっています。

まとめますとマイコン系のキーボード操作体系は以下の区分けができるようです。

１９７５年以前　モニタOS付きマイコン＋テレタイプ端末　時代　（これを体験した方は僅かですが）

１９７５年から　BASICインタプリタ＋テレタイプ端末　時代

１９７６年から　CP／M＋テレタイプ端末　時代

　　ここまでがシリアル通信で端末としてキーボードがつながった時代
　　以下がキーボードがCPUに直接接続した時代

１９７８年から　BASIC専用機時代

１９８１年から　MS－DOS時代

１９９０年から　Windows時代

現在のユーザーはWindowsのショートカットに慣れているので、シリアル通信端末時代のコントロールコードによる操作体系を実現しているCP／Mの操作については、混乱を避けるために「頭の切り替え」などの特別な説明が必要と思いました。

今後操作マニュアルを作るときに最初の方のページで、時代背景とコントロールコードの変遷についての説明を行いたいと思います。

以下余談

Windowsキーボードで最も謎のキーが「SysRq」、システムリクエストキーです。

これは使われていません。

これは、マイクロソフト社で初期のWindowsを開発中に「仮想システム」（VM）の技術を取り入れることを計画していて実システムと「仮想システム」との切り替え用に用意したキーです。

当時の大型コンピュータでは仮想システムが流行でした。

初期の１６bitCPUでは「仮想システム」の実現は不可能でしたので挫折して「仮想システム」の機能は無くなりましたが「SysRq」キーだけが残りました。

機能は無くなりましたがWindowsキーボードの規格となっているので現在のキーボードにも残っています。

イルカのひれに太古の時代に足が在ったときの指の骨が残っているのと同じようなものです。

６４bit時代になり、Windowsにも「仮想システム」（VM）の技術が取り入れられましたが、実システムと「仮想システム」との切り替え用に用意した「SysRq」キーが復活することはありませんでした。

現在マイクロソフト社でVM技術を開発している方は若いので２５年前の「SysRq」キーの経緯を知らない可能性が高いです。

マイクロソフト社では挫折した多くのプロジェクトが闇に葬られています。

UNIX系のシステムや特殊用途に「SysRq」キーが一部利用されているようです。

「ＳｙｓＲｑ」キーについてネット検索すると「ホストコンピュータと接続するときに使うらしい・・・」という説明しかありません。

名前からするとそういう理解になりますが、ルーツをたどるとWindowsＯＳの開発初期段階で実ＯＳと仮想ＯＳを実現してＯＳの切り替えを計画していた経緯があります。

実ＯＳと仮想ＯＳの切り替えを行うキーが「ＳｙｓＲｑ」キーでした。

Windowsに実ＯＳと仮想ＯＳが実現していれば、表面的な仮想ＯＳがダウンしても、実ＯＳの管理下でWindows全体がダウンすることはなく、Windowsの信頼性は高まりました。

ブルーパニック画面は不用になっていました。

しかし、当時の１６bitＣＰＵであるi８０８８や、i８０８６は、８０８０に毛が生えた程度の実力でしたので実ＯＳと仮想ＯＳの両方のＯＳを稼動させることはできませんでした。

同じ時代のライバルメーカー「モトローラ社」の１６bitＣＰＵであるＭ６８０００には、実ＯＳと仮想ＯＳを実現する命令体系があり、更にバスエラーを検出するハード機能もありました。

（i８０８６は、約３万トランジスター、Ｍ６８０００は約７万トランジスターでした）

（i８０８８や、i８０８６にはバスエラーの検出機能が無いのでバスエラーを無視しながら動作しているという怖い状況でした。バスエラーは結構高い頻度で発生します。）

モトローラ社のＭ６８０００は、残念ながらＣＰＵの出荷がインテル社より遅れたことと、i８０８８や、i８０８６が、８０８０とアセンブラソースレベルでの互換性が在ったアドバンテージを切り崩すことができませんでした。

モトローラ社は通信関係を得意とする巨大国策会社ですから日本で言えばＮＥＣのような会社です。

当時のインテル社は社員数百人程度のベンチャー企業です。

社員数百人程度の半導体ベンチャーがガチンコ勝負でＮＥＣを打ち負かすという事態は、大手企業ブランドが好まれる日本では考えられない事態です。

無名ブランドでも、良いものはドンドン使おうという米国人気質が新興企業と育て、新興企業が発展して米国経済を牽引する良い循環を生んでいるようです。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

以上、Ｙ様のご了解をいただいて、メールからそのまま転載させていただきました。

ワンボードマイコンでＣＰ／Ｍを！［第７７回］
２０１２．３．３１ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る