標準TTLだけ(!)でCPUをつくろう!(組立てキットです!)
(ホントは74HC、CMOSなんだけど…)
[第574回]
●それって本当に必要な処理?
前回問題になりました改行の処理について、一晩たって、朝になってから、落ち着いて、よくよく考えてみましたら。
むむむ。
なんだかおかしなことをやっておるなあ。
という気がしてきました。
改行コードを読んだときの処理です。
/// CR/LF void vcr() {int i,j,x,y; char wkbf[81]; i=cursor/80;cursor=(i+1)*80; if(cursor==winend||cursor==Vsize&&winend==0) {for(i=0;i<79;i++){vram[i+winend]='\0';wkbf[i]=0x20;} wkbf[i]='\0';cursor=winend;wintop=wintop+80;winend=winend+80; x=wherex();y=wherey(); //printf("%s",wkbf);gotoxy(x,y);//need for win2k start=clock();//test for(i=0;i<79;i++)putc(wkbf[i],stdout); end=clock();//test total=total+(end-start);//test crcntr=crcntr+1; gotoxy(x,y); }
これは前回もお見せしました。
デバッグのために、putc()の前後にclock()を埋め込んでいます。
そのputc()なのですが、これは一体何をやっているのでしょう?
わからないなあ。
ってその昔に自分で書いたプログラムなのですけれど…。
改行を実行したあとで、ということは画面全体が1行上に繰り上がって、カーソルポイントは画面の最下行の左端に来るはずです。
そこで、その最下行の1行分に、再スクロールしないように79個のスペースを表示しています(ここで80個表示するとまたスクロールしてしまいます)。
もっともこれも中途半端で、最後の1文字分はどうなるの?と思うのですけれど、それはともかく。
改行直後ならば、画面の最下行はもともと何も表示されていないはずなので、わざわざそこにスペースコード(0x20)を書くなんてのは、無駄、なのですよねえ。
一体何を考えていたのでしょう。
このソースのもとになるプログラムを書いたのは、今よりももっとCについての初心者だったころでしたから、おそらくこのような無駄を書いていてもそれに気がつかなかったのでしょう。
ただの無駄ならばそのままにしておいてもよいのですけれど、このputc()のおかげでさんざ苦労させられてしまったのでありますし、今もなお、これが残っているおかげで、PRINT文がめっちゃ遅くなってしまっているのでありますから、こういうものは削除してしまうに限ります。
ということで、えいやっと、削除してしまいまして、例のPRINT文を実行してみましたら。
おお。
速い。速くなりました。
今まで16秒ほどもかかっていた、改行有りのPRINT文1000回の実行が、改行無しのときと同様2〜3秒で終了するようになりました。
いやあ、めでたし、めでたしです。
これにて一件落着。
●本当は必要でした!
めでたし、めでたし、のはずだったのでありますが…。
世の中というものは、なかなか思うようには、なってくれないものであります。
虫の知らせといいましょうか、ふっと気になりまして。
そういえば、Windows2000ではまだ一度も試していないけれど、大丈夫だろうか?
大丈夫じゃなかったのですよお。
じつは。
前にも何回か説明しておりますように、Z80BASICの相方といいますか、DOSプロンプトで実行するほうの、C++のプログラムZB2x(まだデバッグ中ですのでプログラム名に2xがついております)は、当社のZBKシリーズの開発用のプログラムとして、5年ほど前に作ったものがもとになっているのですが、そのもとになったプログラムには、ところどころに、「Windows2000に限り必要」なるコメントを付したところがあるのです。
上でお見せしました改行処理ルーチンvcr()にも、それがあります。
/// need for win2k for(j=0;j<68;j++)wkbf[j]=0x20; wkbf[j]='\0'; //printf("%s",wkbf); for(j=0;j<68;j++)putc(wkbf[j],stdout); /// gotoxy(1,24);
なんだかしつこくスペースを書き込んでいるようです。
なんでこんな無駄なことをやっておるのかいなあ、と思っていたのでありますが。
それが、無駄なことじゃなかったのです。
ちょいと気になりましたので、普段はお休みしておりますWindows2000を久しぶりに起動させまして、Z80BASICのシステムを実行させてみましたところ…。
や、や、や。
画面がクリアできません!
画面をスクロールさせてみますと、Windows98上ならばプランクで上がってくるはずの最下行に、以前の表示がそのまま残ったままで上がってくるではありませんか。
しつこくスペースコードを書き込んでいたのには、ちゃんとした理由があったのでした。
うう。
わかった。わかりましたよ。
でも、でも。
そうすると、このputc()は削除できないことになってしまうじゃありませんか。
んでも、こんなものがあるためにPRINT文がめっちゃ遅くなってしまうのですから、こいつを残しておくわけにはいきませんです。
つうことは、そこをクリアするためには、Windows98版とWindows2000版の2本立てにするしかない。
うう。
そんな10年前のOS用にわざわざ2本も別々に作るのかあ?
それなら、この際、Windows2000は対象外、ということで。
あの、Windows98の方がより古いのでございますが…。
いいの。
こーいうものは、独断と偏見で決定するものなの。
私としては、Windows98を取りたいの。
●やっぱり!XPも…
さらに、さらに、気になりまして、WindowsXPについても確認をしてみることにいたしました。
私の場合、普段の作業はいまだにもっぱらWindows98で作業全般をこなしておりまして、したがいまして、Windows2000もWindowsXPも普段はほこりをかぶってひたすらお休みなさっております。
で。
久しぶりにWindowsXPを起動させて、同じくUSBでND80ZVを接続して、Z80BASICを実行させてみたのでありますが。
おんなじだったんですよお。Windows2000と…。
そういえば、やっと、気が付きました。
Windows2000とWindowsXPでは、DODプロンプトの右にスクロールバーがついていたのですねえ。
スクロールして画面の上に消えてしまったはずの表示も、このスクロールバーを操作すると、画面に戻すことができます。
これができるなら、ページモードなどわざわざ作る必要はないではないの?
あ。
でも、表示そのものはスクロールして戻すことができるのですけれど、カーソルの移動はできないようですねえ。
つまり、過去を呼び戻して、再び表示させることはできるけれど。
うう。
過去は変えられない?
まるで、あれだ。タイムパラドックスかあ。
現在カーソルがある行で、表示されている範囲の中でだけ[←][→]で移動できるけれど、[↑][↓]で別の行に移動はできないようです。
つまりはスクリーンエディタではなくて、依然として、ラインエディタのまま。
なんとも中途半端な機能としか思えないのでありますが。
ともあれ。
こうなってくると、やっぱり、Windows98版とWindowsXP/2000版の2本立てにせざるを得ないようでありまして。
いままで、Windows98の上でのみ、動作確認をしてきましたので、こうやってあらためてWindowsXPの上で走らせてみますと、画面がクリアされなかったり、カーソルが引っかかって動いてくれないときがあったり、いろいろな不具合がみつかってしまいました。
やれやれ。
せっかくZ80BASICの動作確認もほぼ完了するところまできたと思いましたのに。
これから、また、WindowsXPの上でもうまく動いてくれるように、調整していかなければなりません。
まだまだ、当分、暑い夏が続きそうです。
あ。
ひとつ書き忘れがありました。
さきほどのWindowsXPでの動作ですが、念の為に、putc()の実行時間を測定してみましたところ、Windows98では16秒ほどもかかってしまっておりました、改行有り1000回のPRINT文なのですが、XPでは同じプログラムが1.5秒で終了してしまいました。
もっともこちらのパソコンはCeleron2.2GHzでちょいと速いのですけれど。
それにしても速い!
これなら何の問題もありません。
どうやら、putc()がHID通信の影響を受けるらしい、というのはWindows98に限って、ということのようです。
2010.8.5upload
前へ
次へ
ホームページトップへ戻る