標準ＴＴＬだけ（！）でCPUをつくろう！（組立てキットです！）
(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第５８３回］

●ＰＩＣＳＴＢがおかしい

前回、ＰＩＣ１８Ｆ１４Ｋ５０からＺ８０ＣＰＵ側に２３２Ｃ受信データを渡しているところをロジアナで記録した波形を見まして、おかしいところがあることに気が付きました、と書きました。
まずはそのことについて説明をいたします。

これは前回最初にお見せした波形です。
１６，１７と続くデータの、　，１　の部分を渡しているところです。

おかしなところというのは、図の矢印で示した①の立下り部分です。
この信号はＰＩＣ１８Ｆ１４Ｋ５０がＺ８０にデータを渡すときに、そのデータをセットしたことをＺ８０に示すためのＳＴＢ信号です。
処理の流れから、このデータは２３２Ｃ受信データなのですが、ここでデータがセットされるのはあきらかに間違っています。

①の立ち下りは、その上の２３２Ｃセレクト信号が立ち上がったあとのタイミングになっています。
なぜ？
おかしいのはそこなのです。

ＰＩＣＳＴＢ信号は、２３２Ｃセレクト信号の立ち下りを見て、出力されるべきなのです。
次のデータを受け取るために２３２Ｃセレクト信号が立ち下るのは、②のタイミングですから、ほんとうは②のあとで、①の立ち下りが来なければいけないはずです。

もうひとつおかしいところがあります。
③の立ち下りも、①と同じ理由でおかしいのです。
このときは、受信バッファにデータが残っていなかったらしく、受信バッファエンプティを返しているために、ＰＩＣＳＴＢは１５μｓｅｃ程度で立ち上がっています。

この受信バッファエンプティの信号も、本当は④のタイミングが正しいのです。
なぜか③で余計な応答をしてしまっています。
なぜか、と書きましたがもちろん今はその理由はわかっています。

●ＰＩＣ１８Ｆ１４Ｋ５０のデータ送出プログラムに甘いところがありました

ＰＩＣ１８Ｆ１４Ｋ５０のデータ送出ルーチン（ｄｔｏｕｔｓｕｂ）のソースリストです。
このリストは上で指摘した問題点を修正したあとのものです。

dtoutsub
        movwf datawk
        btfsc PORTC,4
        iorlw 10;rc4=1 (232cerror none)
        btfss PORTC,4
        andlw 0f;rc=0 (232cerror)
dtoutsub1
        btfss PORTC,5;wait till cpu READY
        goto dtoutsub1
        movwf PORTC;low 4bits out
        bcf PORTB,4; STROBE out
dtoutsub2
        btfsc PORTC,5; wait till cpu BUSY
        goto dtoutsub2
        bsf PORTB,4; STROBE off
; High 4 bits data out
        rrncf datawk
        rrncf datawk
        rrncf datawk
        rrncf datawk,w
        btfsc PORTC,4
        iorlw 10;rc4=1 (232cerror none)
        btfss PORTC,4
        andlw 0f;rc=0 (232cerror)
dtoutsub3
        btfss PORTC,5; wait till cpu ready
        goto dtoutsub3
        movwf PORTC;high 4bits out              
        bcf PORTB,4; STROBE out
dtoutsub4
        btfsc PORTC,5; wait till cpu BUSY
        goto dtoutsub4
        bsf PORTB,4; STROBE off
dtoutsub5
        btfss PORTC,5;wait till cpu ready & 232c off
        goto dtoutsub5
        btfss PORTC,7
        goto dtoutsub5
        return

このことに気が付く前は、一番最後の
ｂｔｆｓｓ　ＰＯＲＴＣ，７
ｇｏｔｏ　ｄｔｏｕｔｓｕｂ５
が無かったのです。

当初は、この部分が無かったために、２３２Ｃセレクト信号の立ち上がりを確認しないでリターンしていました。
２３２Ｃセレクト信号もじきに立ち上がるのですが、ＰＩＣ１８Ｆ１４Ｋ５０は何しろクロックが４８ＭＨｚですから、実に速いのです。
前回お見せしたフローチャートをあっという間に一巡してしまって、まだ２３２Ｃセレクト信号が立ち上がる前に、次の２３２Ｃセレクト信号のチェックルーチンにエントリしてしまっていたのです。

③の立ち下りが発生してしまったのもまったく同じ理由からでした。

そして、問題のデータの欠落部分です。

⑤の立ち下りが誤りであることは上で説明した理由と全く同じなのですが、今度はまだ受信データが残っているために、Ｚ８０がそれを引き取るまでずっと待っています。
Ｚ８０ＣＰＵ側は、かなり時間が経ってから、約１２０μｓｅｃ後に、Ｚ８０ＢＵＳＹ信号をアクティブにして、データを引き取っています。

ところが良く見ますと、２３２Ｃセレクト信号は上がったままです。
ということはＺ８０ＣＰＵは、このときのデータは２３２Ｃ受信データではなくて、ＵＳＢ（ＨＩＤ）経由でＷｉｎｄｏｗｓパソコンから送られてきたデータとして受け取っているらしいことになります。
しかし、ＰＩＣ１８Ｆ１４Ｋ５０の側は、２３２Ｃ受信バッファのデータを渡しているのです。

なぜこのような食い違いが起きてしまったのでしょうか。
じつは、前回の出力データの説明にもありましたように、このときのコード［３７］つまり文字’７’が、Ｚ８０ＢＡＳＩＣで２３２Ｃ受信データを格納していたＡ＄に３９バイト目のデータとして入れられたので、一旦ＲＥＡＤ　＃１命令が終了して、次の処理に移っていたのです。

Ｚ８０ＢＡＳＩＣは、実行中にＷｉｎｄｏｗｓパソコンのキーボードから［Ｃｔｒｌ］［Ｂ］を入力することでブレイクさせて、実行を中止することができます。
その機能のために、Ｚ８０ＢＡＳＩＣでは、各行の先頭部分で毎回ブレイクキーの入力の有無をチェックしています。
上のロジアナの波形にあった、Ｗｉｎｄｏｗｓパソコンからのデータとして受け取っているのは、そこだったのです。
しかしブレイクチェックルーチンではブレイクコード（００）にしか反応しませんから、そこで受け取ったコード（２Ｃ）は結局捨てられてしまったのです。

ところで、前回お見せしましたように、Ａ＄に３９バイトのデータが溜まる以前にも、ひんぱんにＲＥＡＤ　＃１が終了して次の処理に移っていたはずなのに、なぜ、３９バイトのデータが溜まったときに限って、上で説明したようなデータの欠落が起きたのでしょうか。

これには、かなり悩みました。
なぜだろうか？
たまたま、とか偶然に、とかといって片付けるにはちょっと無理があります。
何か理由があるはず。

やっと、そのわけがわかりました。
その理由は、ＲＥＡＤ　＃１の処理ルーチンの仕組みにありました。
前回説明しましたように、ＲＥＡＤ　＃１命令は、そこで受信待ちでハングアップしてしまわないように、受信バッファエンプティを受け取ったときは、すぐにリターンします。
受信データがあるときは、文字変数にそのデータを追記していきますが、文字変数に３９バイトのデータが格納されると、データの受け取り処理を中断して、ＲＥＡＤ　＃１を一旦終了してしまいます。

参考までに、Ｚ８０ＢＡＳＩＣのＲＥＡＤ　＃１部分のプログラムリストです。

              ;;;
3946 13       RDURA:INC DE
3947 CD262A   CALL ICALC
394A 7D       LD A,L
394B FE01     CP 01
394D C21F3A   JP NZ,ER3E;=62
3950 CD0E3A   CALL RDHNS
3953 C21F3A   JP NZ,ER3E
3956 E5       PUSH HL
3957 CD0E3A   CALL RDHNS
395A FEF2     CP F2
395C C21F3A   JP NZ,ER3E
395F DDE1     POP IX
3961 DDE5     PUSH IX;A$
3963 E5       PUSH HL;A%
3964 4E       LD C,(HL)
3965 23       INC HL
3966 46       LD B,(HL)
3967 DDE5     PUSH IX
3969 E1       POP HL
396A 03       INC BC
396B 79       LD A,C
396C B0       OR B
396D CA7D39   JP Z,SIN2;A%=-1
3970 0B       DEC BC
3971 79       LD A,C
3972 B0       OR B
3973 CA7C39   JP Z,SIN1
3976 E1       POP HL
3977 DDE1     POP IX
3979 C3EE2F   JP STEND
397C 77       SIN1:LD (HL),A
397D 7E       SIN2:LD A,(HL)
397E FE27     CP 27
3980 D2A839   JP NC,SINFUL;A$=FULL
3983 23       INC HL
3984 D5       PUSH DE
3985 1600     LD D,00
3987 5F       LD E,A
3988 19       ADD HL,DE
3989 47       LD B,A
398A 3E27     LD A,27
398C 90       SUB B
398D CDB439   CALL RDSB
3990 D1       POP DE
3991 E1       POP HL
3992 DDE1     POP IX
3994 DD7000   LD (IX+00),B
3997 CAAD39   JP Z,SINEND
399A 78       LD A,B
399B FE27     CP 27
399D CAAB39   JP Z,SINFUL2
39A0 3EFF     LD A,FF
39A2 77       LD (HL),A
39A3 23       INC HL
39A4 77       LD (HL),A
39A5 C3EE2F   JP STEND
39A8 E1       SINFUL:POP HL
39A9 DDE1     POP IX
39AB 0628     SINFUL2:LD B,28
39AD 70       SINEND:LD (HL),B
39AE 23       INC HL
39AF 3600     LD (HL),00
39B1 C3EE2F   JP STEND
              ;
39B4 08       RDSB:EX AF,AF'
39B5 C5       RDSB2:PUSH BC
39B6 06EB     LD B,EB
39B8 78       LD A,B
39B9 D398     OUT (98),A
39BB DB94     RDSB3:IN A,(94)
39BD E620     AND 20
39BF C2BB39   JP NZ,RDSB3
39C2 3E0A     LD A,0A;WAIT ABOUT 20MICROS
39C4 3D       RDSB32:DEC A;(4)
39C5 C2C439   JP NZ,RDSB32;(10)
39C8 DB94     IN A,(94)
39CA E620     AND 20
39CC C2F739   JP NZ,RDSB4
39CF DB94     IN A,(94)
39D1 E610     AND 10
39D3 F5       PUSH AF
39D4 CDA706   CALL RSIN
39D7 3EEF     LD A,EF
39D9 D398     OUT (98),A
39DB F1       POP AF
39DC CAFD39   JP Z,SINER;=73
39DF 79       LD A,C
39E0 C1       POP BC
39E1 FE0A     CP 0A
39E3 C8       RET Z
39E4 FE0D     CP 0D
39E6 CAB539   JP Z,RDSB2
39E9 77       LD (HL),A
39EA 23       INC HL
39EB 04       INC B
39EC 08       EX AF,AF'
39ED 3D       DEC A
39EE CAF539   JP Z,RDSB33
39F1 08       EX AF,AF'
39F2 C3B539   JP RDSB2
39F5 3C       RDSB33:INC A;reset zf
39F6 C9       RET
39F7 3EEF     RDSB4:LD A,EF
39F9 D398     OUT (98),A
39FB C1       POP BC
39FC C9       RET
              ;
39FD F1       SINER:POP AF;DUMMY
39FE F1       POP AF;DUMMY
39FF D1       POP DE
3A00 E1       POP HL
3A01 71       LD (HL),C
3A02 23       INC HL
3A03 3600     LD (HL),00
3A05 3EEF     LD A,EF
3A07 D398     OUT (98),A
3A09 3E49     ER49:LD A,49
3A0B C33D31   JP ERRDP

［以下の説明部分を書き直しました（２０１０．８．１５）］
文字変数に３９バイトのデータが入れられると、それ以上はその文字変数にデータを入れることはできません（Ｚ８０ＢＡＳＩＣの文字変数は３９バイトの固定長です）。
そこでその文字変数のデータを処理できるようにするために、一旦ＲＥＡＤ　＃１を終了します。

このことは、ＰＩＣ１８Ｆ１４Ｋ５０の２３２Ｃ受信バッファにデータが残っていても、残っていなくても、それとは関係なしにＺ８０ＢＡＳＩＣ側の事情（文字変数に３９バイトのデータが格納されたこと）によって発生します。
もしまだ受信バッファにデータが残っている場合には、ＰＩＣ１８Ｆ１４Ｋ５０は続いて残っているデータを送出しようとすることになりますが、Ｚ８０ＢＡＳＩＣ側は、文字変数のデータを処理して、ふたたびＲＥＡＤ　＃１ルーチンにエントリしてくるまでの間は、その受信データを引き取ることはできません。

そこで、ＲＥＡＤ　＃１ルーチンでは、受信データを１バイト引き取るごとに、２３２Ｃセレクト信号をアクティブにするようにしているのです。
ＰＩＣ１８Ｆ１４Ｋ５０は、２３２Ｃセレクト信号が立ち下がったら、Ｚ８０側に受信データを１バイト送り出します。
ＲＥＡＤ　＃１ルーチンで、２３２Ｃセレクト信号をアクティブ（出力Ｌ）にしているところは、上のリストのアドレス３９Ｂ９です。
Ｉ／Ｏアドレス９８のビット２が、２３２Ｃセレクト信号です。
この出力ラインはＰＩＣ１８Ｆ１４Ｋ５０のＰＯＲＴＣのビット７につながっています。
２３２ＣセレクトラインをＯＦＦ（出力Ｈ）にしているところは、アドレス３９Ｄ９、３９Ｆ９です。

このラインを１バイト受信するごとにアクティブにして、ＰＩＣ１８Ｆ１４Ｋ５０からのデータ送出をコントロールしていたつもりだったのですが、ＰＩＣ１８Ｆ１４Ｋ５０のプログラムで、２３２Ｃセレクト信号がＯＦＦ（Ｈ）になるのを確認しないで、Ｚ８０へのデータ送出ルーチンからリターンしていたために、Ｚ８０側が受け取った１バイトのデータの処理を完了して２３２ＣセレクトラインをＨにするよりも前に、ふたたびＰＩＣ１８Ｆ１４Ｋ５０のデータ送出ルーチンが実行されていました。

Ｚ８０ＢＡＳＩＣの側では、まだ文字変数に３９バイトのデータが格納されるまでの間は、引き続きＲＥＡＤ　＃１ルーチンの中で、次のデータを受け取りますから、ＰＩＣ１８Ｆ１４Ｋ５０が、先にデータを送出するようにしていても、そこでは問題は発生することなく、データの受け渡しが行われます。

もしＰＩＣ１８Ｆ１４Ｋ５０の２３２Ｃ受信バッファにデータが残っていない場合には、さきほどのロジアナ波形の矢印③のように、受信バッファエンプティの誤出力になりますから、わずか１５μｓｅｃの期間だけアクティブになるだけです。
ＰＩＣ１８Ｆ１４Ｋ５０のクロック４８ＭＨｚは非常に高速ですが、Ｚ８０は６ＭＨｚですから、それに比べればかなりゆっくりしています。
矢印③のパルスはＺ８０ＢＡＳＩＣでは認識されることなくパスされてしまっているのですが、もしもＺ８０の処理がもう少し速くて、③のパルスを認識していたとしても、その場合には、やっぱり受信バッファエンプティとして処理されますから、したがって、この場合にもなんの問題も発生しません。

結局、まだＰＩＣ１８Ｆ１４Ｋ５０の受信バッファに、送出されていないデータが残っているときに、文字変数にデータが３９バイト格納されて、そこでＲＥＡＤ　＃１が終了した時に限って、ＰＩＣ１８Ｆ１４Ｋ５０は次のデータをセットして、それをＺ８０側が引き取るまでスタンバイすることになり、そしてそのときには、Ｚ８０ＢＡＳＩＣではブレイクコードのチェックが行われるために、上で説明した「食い違い」によって、データの欠落が発生することになったのです。

文字変数データに３９バイトのデータが格納されてＲＥＡＤ　＃１が終了したときに、たまたまＰＩＣ１８Ｆ１４Ｋ５０の２３２Ｃ受信バッファが空になっていた場合には、矢印③の受信バッファエンプティが出力されますが、これは既に説明しましたように、出力されるタイミングが速すぎてＺ８０側では認識できませんから、そのままパスされてしまいます。
したがって、このときには、文字変数が３９バイトになっても、データの欠落はおこりません。

データの欠落は、文字変数にデータが３９バイト入れられた直後に発生していましたが、しかし、文字変数にデータが３９バイト入れられた直後でも、発生していないところもありましたが、そのときは、たまたま受信バッファが空になったときだったのです。
［ここまで２０１０．８．１５書き直し］

プログラム修正後の波形です。

ＰＩＣＳＴＢの誤出力は無くなっています。
もちろん、データの欠落は発生しなくなりました。

>.
    10 A%=0
    20 READ #1,A$,A%
    30 IF A%<1 GOTO 20
    40 PRINT A$
    50 GOTO 10
>r.
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,1
6,17,18,19,20,21,22,23,24,25,26,27,28,2
9,30,31,32,33,34,35,36,37,38,39,40,41,4
2,43,44,45,46,47,48,49,50,51,52,53,54,5
5,56,57,58,59,60,61,62,63,64,65,66,67,6
8,69,70,71,72,73,74,75,76,77,78,79,80,8
1,82,83,84,85,86,87,88,89,90,91,92,93,9
4,95,96,97,98,99,100,101,102,103,104,10
5,106,107,108,109,110,111,112,113,114,1
15,116,117,118,119,120,121,122,123,124,
125,126,127,128,129,130,131,132,133,134
,135,136,137,138,139,140,141,142,143,14
4,145,146,147,148,149,150,151,152,153,1
54,155,156,157,158,159,160,161,162,163,
164,165,166,167,168,169,170,171,172,173
,174,175,176,177,178,179,180,181,182,18
3,184,185,186,187,188,189,190,191,192,1
93,194,195,196,197,198,199,200,201,202,
203,204,205,206,207,208,209,210,211,212
,213,214,215,216,217,218,219,220,221,22
2,223,224,225,226,227,228,229,230,231,2
32,233,234,235,236,237,238,239,240,241,
242,243,244,245,246,247,248,249,250,251
,252,253,254,255,end


２０１０．８．１４ｕｐｌｏａｄ
２０１０．８．１５一部更新

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