IBM JX -- 拡張バス デバッグ・ツール DebTool ― 2026年05月17日 19:45
IBM JX -- P.D.ツール MFG_PORTアダプター ― 2026年05月16日 10:10
POSTが出力するテストステップとエラーコードを表示するツール P.D.ツール MFG_PORTアダプターを制作しました。簡単に言えば、I/Oポート、MFG_PORT,+1,+2に出力された値を表示するアダプターカードです。
- MFG_PORT: テストステップ
- MFG_PORT+1:エラーコード (H)
- MFG_PORT+2:エラーコード (L)
ブロックダイアグラムはこんな感じです。アドレスデコーダーやバイナリーから7セグメントLEDデータへの変換は、GAL16V8で作りました。データバスには74ALS574が3つぶら下がるので、バッファーを入れたほうが良かったかも。これで動いてますので、結果オーライと言うことで。
このようなものができました。6桁のLEDを持つアダプターです。
回路図は、こちらです。GALのデザイン・データも入れてあります。(* 2026/5/17: 回路図をアップデートしました。)
MFG_PORT.ZIP (270960 Byte)
制作は、Step By Stepで。まずは、電源ラインを配線したら、JXの拡張コネクタに挿して、問題が再現されることを確認。次に、アドレス・バス、そして、データ・バス。それから、残りを配線して、組み立ては完了です。
完成したMFG_PORTアダプターの動作確認をしておかないと、表示された値が正しいものかどうか、確信が持てません。GALについては、ブレッド・ボードにテスト回路を組み、動作を確認してあります。配線した部分を 確認しないことには。
というわけで、簡易なDebugツールを制作します。
IBM JX -- POST ― 2026年05月05日 13:30
POST(Power On Self Test)を 読みました。8088/86はこう使うのかと、勉強になります。
MFG_PORTに、何やら書き込んでます。この先を読んでみますと、テストステップの開始にMFG_PORTにコードを書き込んでます。
| TEST STEP | MFG_PORT CODE | TEST ITEM |
|---|---|---|
| SET UP | 0FFH | SETUP |
| 1 | 8088 | |
| 2 | 0FEH | 8255 |
| 3 | 0FDH | 64505,VIDEO |
| 4 | 0FCH | ROS CHECK SUM |
| 5 | 0FBH | RAM MAPPING |
| 6 | 0FAH | BASE 4K STORAGE |
| 7 | 0F8H | ROM CARTRIDGE |
| 8 | 0F7H | INTERRUPT |
| 9 | 0F6H | 8259 |
| 10 | 0F5H | 8253 |
| 11 | 0F4H | CRT ATTACHMENT |
| 12 | 0F3H | SET UP KEYBOARD PARAMETERS |
| 13 | 0F2H | 32K VRAM |
| 14 | 0F1H | KJ-ROM AND GAIJI SRAM |
| 15 | 0F0H | MEMORY SIZE DETERMINE |
| 16 | 0EFH | KEYBOARD |
| 17 | 0EEH | CASETTE INTERFACE |
| 18 | 0EDH | SERIAL PORT |
| 19 | 0ECH | PARALLEL PORT |
| 20 | 0EBH | OPTIONAL ROM |
| 21 | 0EAH | DISKETTE ATTACHMENT |
| 22 | 0E9H | PCjr CARTRIDGE ROM CHECK SUM |
エラーを検出すると、E_MSGサブルーチンを使って、エラーコードをMFG_PORT+1,MFG_PORT+2に書き出します。そして、ビデオのテスト前だと、ビープを2回鳴らします。出だしは、こんな感じです。
MFG_PORTを読み取る"MFG-PORT Adapter"を制作してます。
IBM JX -- POST ERROR ― 2026年04月23日 21:45
せんだて、入手したIBM JXにアップスキャンコンバーターを経由してVGAディスプレイを 接続したのですが、あの、本体起動直後のカラーの画面が表示されません。
BEEP音が2回しますので、POST(Power On Self Test)でハードウェア・エラーを検出しています。検出したエラーは、画面に表示されるのですが。
そもそも、ディスプレーには何も映らないので、どうして良いのやら。
まず、アップスキャンコンバーターのロゴやメニューが表示されるので、コンバーターは生きています。
更に、コンバーターは、"NO SIGNAL"と言ってきます。JXのディスプレーポートとコンバーター間の
接続を再確認。間違いなし。
念の為、JXのディスプレーポート J15 の信号を確認したところ、以下のようでした。
| PIN# | NAME | SIGNAL |
|---|---|---|
| 1 | GND | |
| 2 | R | NO SIGNAL |
| 3 | -HSYNC | NO SIGNAL |
| 4 | -VSYNC | NO SIGNAL |
| 5 | H/-LSW | OK |
| 6 | I | OK |
| 7 | B | NO SIGNAL |
| 8 | GND | |
| 9 | GND | |
| 10 | G | NO SIGNAL |
| 11 | COLOR CLOCK | OK |
| 12 | +12V | |
| 13 | DOT CLOCK | OK |
| 14 | AUDIO | |
| 15 | GND |
"I"や"H/-L SW"が出てきているので、IC69 74LS240は、生きてるでしょう。"I"はカスタムICのIC32 SX001から来る信号なのです。IC32も生きてるように感じます。
ということは、Display関連のテストとそれ以前のテストで、POSTが障害を検出したのは間違いないのですが、このままでは、 場所を特定できません。
というわけで、POSTを読んでます。
ユーザーに優しくないシステム ― 2026年04月23日 09:00
私達は、日々、コンピューターを利用したシステムを使っています。パソコンや携帯電話、スマートフォンを
使用しない日は、ないでしょう。それで使用する機能は何でしょうか?
- ネットサーフィン。
- インターネット・メールのやり取り。
- youTubeで動画を視聴。
- Xでつぶやく。
- Amazon Prime Videoで名探偵コナンを視聴。
- etc. ...
両手の指では数えられないほどあるでしょう。みなさん、それぞれの利用の仕方・楽しみ方があるでしょう。
そして、大多数の方はインターネット・メールを利用していることと思います。
私もこのAsahi-netのメール・アドレスだけでなく、auや他のメール・アドレスを持っています。実際に使っているのは一部だけですがね。
せんだて、auメールで痛い目にあいました。調べてみると、「ユーザーに優しくないシステム」が露わに。
ことの発端は、今年の1月下旬、なんの前触れもなく、多数の古いメールが削除されてしまったことです。 調べてみると、 auメールにはサーバー側に保管してあるメールの件数と総データ量に制限があり、この制限を超えると、 古いメールから必要数を メールサーバーが(強制的かつ)自動的に削除する仕様になっていることがわかりました。 「容量の上限に近づいた」とか「メールを削除しますよ」と言ったお知らせはないのです。 ユーザーは削除されてしまってから、この制限に達したことを知ることになります。 せめて、「ゴミ箱」フォルダーのメール優先でやってくれれば、悲劇は減るでしょうに。
メールの管理は、ユーザーが行うことになってますが、自分のメールの総量を知る手段はありません。 メールアプリは、そもそも、そのような機能が、iMAPにありませんので、知る由もなしです。
auが提供している「My au」アプリがあります。これで、データ通信量はわかりますが、メールの総量はわかりません。
この状況で、ユーザーは、いったい、いつ、不要なメールを削除すればよいのでしょうか?自分のメールの総量を知るすべがないので、 わかりません。
iMAPによるメールの配信サービスですから、ユーザーが受信したメールは全てメールサーバー側にあります。 「auメールのサーバーの管理業務は大変だろうなぁ」と感じてましたが、こんな仕様になっているとは。
更に調べてみると、同じauがサービスしている他のメールサービス「au-Oneメール」では、 容量の上限に近づくとユーザーにお知らせが出ることになってます。 「同じauなのに、同じようにお金払ってるのに、なんで違うの?」、理由を想像できません。メールサーバーの中身はほぼ同じと思いますが。
各ユーザーごとのメールの総量を定期的に調べる機能は、どちらのメールサーバにも備わっています。 この機能がなければ、古いメールを削除する機能を動かすタイミングを知ることができません。ですので、 あるユーザーのメール総量が限界に近づいていることをメールサーバーは確実に知ることができます。 あとは、該当ユーザーにお知らせを出すだけです。これは、自動的にできます。このぐらいの気配りはできるでしょう。しかし、やらなかった。 システム設計の基本構想の不備、「ユーザー視点の欠落」。致命的なミスです。ユーザーに知らせずに勝手に削除したら、何が起こるか、 ユーザーはどんな反応をするかを 想像できなかったんでしょうね。「ユーザーに優しくないシステム」を 作ってしまったね。
さて、このauメールサービスの容量制限は、緩和策があります。オプションの「Pontaパス」に入会すると、 容量がほぼ倍増します。倍増するタイミングは、「Pontaパス」に加入したタイミングでは「なく」、 Webブラウザーで「Webメール」サイトにアクセスした時点です。このようにしている理由を想像できません。
いや、一つだけ想像できます。それは、メールサーバーの運用管理を楽したいからです。「Pontaパス」に入会した時点で 制限を緩和する仕組みにすると、メールサーバーの物理的容量を頻繁に増量する必要が出てきそうです。これを 逃げるために、「Webメール」をアクセスした時点で、初めて、容量制限を緩和することにしたのでしょう。 「Pontaパス」に加入したユーザー全員が、容量緩和を目的で加入するわけではないでしょうからね。
ここにも、「ユーザーに優しくないシステム」の一面が見えます。
auメールのトラブルに見舞われてから3ヶ月、先日、添付のメールが、auから来ました。
ほんの少し、auメールのメールサーバーでメールを削除するロジックを変更するようです。今頃か。
これでも、まだまだ、不十分です。「ゴミ箱」フォルダーのメールを 優先して定期的に削除しても、
メール総量に達することが、予想されます。やはり、ユーザーにメールの削除・整理を
依頼する必要があるでしょう。付け焼き刃というか、焼け石に水、それとも、モグラ叩き。最小の費用でと
考えたのでしょうが、これではねぇ。問題の解決には、至らないでしょう。無駄な費用を 費やしただけですね。
「ユーザーに優しいシステム」という視点がない、「自分たちの都合最優先のシステム作り」をやめてください。
私事ですが、現役のとき、このような視点に基づいた基本計画・設計のシステム提案書をお客様に持っていったら、 良くてゴミ箱に捨てられる、悪くすれば出入り禁止になってたね。実際に使用するお客様の視点で、 システム基本計画・設計することを常に求められていたし、それは暗黙の了解事項だった。
クレームがあったら、ちょこっと修正してお茶を濁し、ほとぼりが冷めるのを待つ。無責任時代になったのか?
この前、若いauの社員と話す機会があったのだが、KDDIの前身、「国際電電」を
知らなかった。昭和は遠くに成りにけりか。今が良ければ過去なんてかな。
ご参考のため、auからのメール(必要な部分のみ)掲載します。公式なメールだから、公開してもいいよね、auさん。
いま、読みなおして気づいたのだが、「自動削除される場合があります。」とあるが、これは、「自動削除されます。」
の間違いなのでは?それより、「ゴミ箱」フォルダー内のメールを自動削除する機能は、以前からあったっけ?
「#90日以前の受信メール」フォルダーにあるメールを自動削除する機能は、あったと思うが。ユーザーを煙に巻く、
いやな感じ。
========================= auからのメール 関連部分のみ (ここから) ============================= 差出人: auからの重要なお知らせ日時: 2026年4月21日 10:18:06 JST 宛先: ########@ezweb.ne.jp 件名: auメールご利用のお客さまへの重要なお知らせ いつもauメールをご利用いただきありがとうございます。 このたび、auメールをより安心・快適にご利用いただくため、以下2点をご案内いたします。 1.「迷惑メールおまかせ規制」の判定精度向上 2.auメールサーバのゴミ箱内メールの自動削除仕様改善 1.「迷惑メールおまかせ規制」の判定精度向上について ((((( 省略 By Kida )))) 2.auメールサーバのゴミ箱内メールの自動削除仕様の改善 「ゴミ箱」に移動したメールがたまり続けると、容量不足が影響し、受信ボックス内のメールが先に自動削除される場合があります。 このたびメールサービスを、より快適にご利用いただけるよう、2026年6月より順次、auメールサーバのゴミ箱内メールの自動削除仕様を改善します。 ■ 変更内容 「ゴミ箱」フォルダにあるメールのうち、受信日から45日を経過したメールを、サーバから自動的に削除します。 本仕様変更の対象のお客さまや開始時期などの詳細・最新情報については、以下のURLよりご確認ください。 > https://www.au.com/mobile/service/email/ -------------------------------- ■ お問い合わせ チャット 受付時間 AI:24時間/年中無休 (コミュニケーター:9:00-20:00) au:https://kddi-l.jp/Ika ========================= auからのメール 関連部分のみ (ここまで) =============================
とうとう、武器商人国になってしまった。 ― 2026年04月22日 21:10
この場に、このようなことを書き込むことに、非常に強い悲しみを感じる。
あらゆる兵器、殺傷能力のありなしに関わらず、よその国に輸出出来ることになったと言う。 国会の承認不要、つまり、最低限の歯止めが無くなった。
私たちは、好むと好まざるに関わらず、殺人の片棒を担ぐ事になる。
私たちは、これを 容認して良いのか?
防衛産業の保護育成は、国の安全保障に必要なのだと言う。防衛産業の基礎になる多くの基礎技術は、民間転用できると言われてきた。
これは事実だったか?
その技術開発に注ぎ込まれる費用、労力は、莫大である。防衛予算を見れば判る。民間での技術開発におけるそれは、足元にも及ばない。
この産業は、一部の上級民だけに必要で、ほとんどの国民には不要な産業じゃないか?
なぜ、高市早苗は、私たちに、こんなにも不安を与えるのだ? 止めてくれ。政治の世界から、退場してくれ。
今年も、クリスマスにはこの曲を 楽しく聴きたい。HAPPY XMAS(War Is Over) JOHN & YOKO/THE PLASTIC ONO BAND
書いてたら、何故か、涙が出てきた。
IBM JX ― 2026年03月20日 17:00
IBM JX 本体を比較的安価に、入手できました。
内容は、
- メモリー 128KB (本体 64KB、64KB メモリーカード)
- 2 Diskette Drive
- 拡張表示カード
JX 本体の上にある本は、
- 「DOSの内部構造とプログラムインターフェイス N:SC18-2016-0」
- 「テクニカル・リファレンス N:SY18-2104-1」
電源は、入りました。BEEP音が2回鳴ったので、ハードウェアーエラーを検出したみたいです。
まずは、ディスプレーとキーボードの接続からでしょうか。
デジタル RGB ディスプレーを入手は、大変でしょうから、今時のVGAディスプレーの接続を検討します。
JX用純正キーボードを望む事も無理ですから、今時のPS/2接続のキーボードを流用を検討します。
これ以外にも、やってみたいことが。
- XT-IDE を移植したい
- 384KB 拡張メモリーアダプターを追加したい
- 拡張ボックスを追加したい
どこまで、できるかな? 当分、楽しめそうです。
GAL Writerの制作 ― 2025年04月14日 17:30
ハードウェアの制作にGALを使用できると、とても便利です。特にアドレスデコーダーの 類などは、とてもすっきりしますし、後からの変更も簡単にできますので、重宝します。 これまで、いくつかの機器の制作で使用してきました。
GALを作成するには、PALASMでヒューズデータを作成し、XGecuのTL866 II Plus
で書き込みをしていました。
これはこれで、いいのですが、PALASMはDOSのプログラムで、 TL866II PlusはWindosのコントルールプログラムでした。そうです。ヒューズデータのやりとりが めんどうだったのです。できれば、DOS環境だけで完結したく思ってました。
調べてみると、GAL Writerの制作例をいくつか発見できました。その中でも、 ELM氏の発表なされた「お手GAL」は、以前より気にかけていたのですが、とてもシンプルで、 DOSの環境で使うことができ、私の悩みを解決するものです。思い切って制作することにしました。 ELM氏の「お手GAL」は ここ にありますのでご参照ください。
実際の制作にあったって、手持ちの部品を優先して使用したので、 古い大型の部品やオーバースッペクの部品が見受けられます。 また、抵抗内蔵のディジタルトランジスタは、抵抗と手持ちのトランジスタで構成しました。 デバッグをしていて、プリンタポートの出力電圧が低かったのでバッファーを追加する必要が でてしまいましたが、大きめのボードだったのでいれることができました。
これが、完成した私の「お手GAL GAL Writer」です。
これで、16V8,20V8,22V10をプログラムできます。今後とも、重宝しそうです。
高速キャリージェネレター付き8ビット加算・減算器の製作 ― 2025年02月06日 21:36
高速キャリージェネレター付き8ビット加算・減算器の製作
デジタル回路の学び直しをしています。テキストは、大川喜邦著「デジタル回路」です。組合せ回路の部分が終わりました。組合せ回路のまとめとして、高速キャリージェネレーター付きの8ビット加算・減算器を基本的なTTLだけで設計、製作しました。最終的には、TTLが30個でできました。
。
ウラ面はこんな感じです。
手ハンダなので、スパゲティボールです。
基板上の"Value A"と"Value B"のスイッチに-128から127までの数値を設定し、加算・減算した結果を"Result"LEDに表示します。負の数は2の補数表現です。
回路図は、ここ にあります。
CPUの中のALUの一部を解析するとこんな感じになるのでしょうね。
Modula-2 でプログラミング -- 文字列探索プログラム find の製作 (その3) -- ― 2025年01月05日 21:19
前回紹介したfindプログラムは、FileSearchモジュールの不備で、ファイル一覧の構造が 丸見えになっていました。FileSearchモジュールに2つ手続きを追加して不具合を解消しました。
新しいFileSearchモジュールの定義モジュールは以下の通り。
DEFINITION MODULE FileSearch;
FROM OpSys IMPORT FCB,FCBFileName;
EXPORT QUALIFIED pFileList,FileNameNode,
GetNextFile,GetFileName,LoginDisk,MakeFileList,DumpFileList;
CONST
DMABufferSize = 128;
FileNameSize = 14;
TYPE
pFileList = POINTER TO FileNameNode;
FileNameNode = RECORD
FileName: ARRAY [0..FileNameSize] OF CHAR;
Next: pFileList
END;
DMA = ARRAY [0..DMABufferSize-1] OF CHAR;
PROCEDURE GetNextFile(FileLIst: pFileList): pFileList;
PROCEDURE GetFileName(FileList: pFileList;VAR FileName: ARRAY OF CHAR);
PROCEDURE LoginDisk(FCBBuf: FCB): CHAR;
PROCEDURE MakeFileList(FIleMatch: ARRAY OF CHAR): pFileList;
PROCEDURE DumpFileList(pList: pFileList);
END FileSearch.
手続き、次のファイルを取り出すGetNextFileとファイル名を取り出すGetFileNameを追加しました。
実現モジュールは以下の通り。
IMPLEMENTATION MODULE FileSearch;
FROM InOut IMPORT WriteHex,Write,WriteString,WriteLn;
FROM OpSys IMPORT FCB,FCBFileName,BdosFunctions,Bdos;
FROM SYSTEM IMPORT ALLOCATE,TSIZE,ADR,WORD;
FROM FileNames IMPORT StrToFCB,FCBToStr,NameState;
CONST
EOS = 0C;
PROCEDURE GetNextFile(FileList: pFileList): pFileList;
BEGIN
RETURN FileList^.Next
END GetNextFile;
PROCEDURE GetFileName(FileList: pFileList; VAR FileName: ARRAY OF CHAR);
VAR
i: CARDINAL;
BEGIN
i := 0;
WHILE ( FileList^.FileName[i] # EOS ) DO
FileName[i] := FileList^.FileName[i];
INC(i)
END;
FileName[i] := EOS
END GetFileName;
PROCEDURE LoginDisk(FCBBuf: FCB): CHAR;
VAR
DiskCode: CARDINAL;
Junk: WORD;
BEGIN
IF FCBBuf.name.disk = 0C THEN
Bdos(retCDsk,Junk,DiskCode);
RETURN (CHR(ORD(DiskCode)+ORD('A')));
ELSE
RETURN (CHR(ORD(FCBBuf.name.disk)+ORD('A')-1));
END;
END LoginDisk;
PROCEDURE MakeFileList(FileMatch: ARRAY OF CHAR): pFileList;
VAR
Disk: CHAR;
FCBBuffer: FCB;
BdosRc: CARDINAL;
DMABuffer: DMA;
CPos: CARDINAL;
NameStatus: NameState;
pList: pFileList;
pNewFileName: pFileList;
FCBFile: FCBFileName;
Formatted: BOOLEAN;
Junk: WORD;
BEGIN
pList := NIL;
(* Clear FCB Buffer and set file name *)
FCBBuffer.name.text := '';
FCBBuffer.rest := '';
NameStatus := StrToFCB(FileMatch,FCBBuffer.name);
Disk := LoginDisk(FCBBuffer);
(* set DMA Bufer *)
Bdos(setDMA,ADR(DMABuffer),Junk);
(* find first much file *)
Bdos(searchFst,ADR(FCBBuffer),BdosRc);
WHILE BdosRc # 255 DO
ALLOCATE(pNewFileName,TSIZE(FileNameNode));
FOR CPos := 0 TO 11 DO
FCBFile.text[CPos]
:= DMABuffer[CPos+BdosRc*32]
END;
FCBFile.disk := CHR(ORD(Disk) - ORD('A') + 1);
FCBToStr(FCBFile,pNewFileName^.FileName,FALSE);
pNewFileName^.Next := pList;
pList := pNewFileName;
(* find next file *)
Bdos(searchNxt,Junk,BdosRc);
END;
RETURN pList
END MakeFileList;
PROCEDURE WriteFileName(FileName: ARRAY OF CHAR);
BEGIN
WriteString(FileName);
WriteLn
END WriteFileName;
PROCEDURE DumpFileList(pList: pFileList);
BEGIN
WHILE pList # NIL DO
WriteFileName(pList^.FileName);
pList := pList^.Next;
END;
END DumpFileList;
END FileSearch.
これらの変更を反映したfindは、以下のとおり。
MODULE Find;
FROM InOut IMPORT Write,WriteCard,WriteString,WriteLn;
FROM Files IMPORT FILE,FileState,Open,Close,Read;
FROM CmdArgs IMPORT Argc,Argv;
FROM FileSearch IMPORT GetFileName,GetNextFile,
FileNameNode,MakeFileList,pFileList;
FROM BasicFileIO IMPORT FileIOStruct,pFileIOStruct,
OpenFile,CloseFile,EOFFile,FileIOStatus;
FROM StdFileIO IMPORT GetLine;
CONST
EOS = 0C;
MAXLINE = 128;
FILENAMESIZE = 14;
EOFMARK = 32C;
VAR
FileName: ARRAY [0..FILENAMESIZE] OF CHAR;
FileMatch: ARRAY [0..FILENAMESIZE] OF CHAR;
Target: ARRAY [0..MAXLINE] OF CHAR;
CPos,FileNumber,LineNumber,nArgc: CARDINAL;
pList: pFileList;
PROCEDURE putLine(FileName:ARRAY OF CHAR;Line:CARDINAL;
Buffer: ARRAY OF CHAR);
BEGIN
WriteString(FileName);
Write(' ');WriteCard(Line,1);Write(':');
WriteString(Buffer);
WriteLn
END putLine;
PROCEDURE findTarget(Target,Line:ARRAY OF CHAR): BOOLEAN;
VAR
t,l: CARDINAL;
found: BOOLEAN;
BEGIN
found := FALSE;
t := 0; l := 0;
WHILE (Line[l] # EOS) AND (NOT found) DO
IF Line[l] = Target[0] THEN
t := 1;
WHILE Line[l+t] = Target[t] DO
INC(t);
END;
IF Target[t] = EOS THEN
found := TRUE;
END;
END;
INC(l);
END;
RETURN found
END findTarget;
PROCEDURE Usage();
BEGIN
WriteString('find');WriteLn;
WriteString(' TargetString File1 File2 FIle3,,,,');WriteLn
END Usage;
PROCEDURE MatchLines(FileName,TargetString: ARRAY OF CHAR);
VAR
pFileIO: pFileIOStruct;
Line: ARRAY [0..MAXLINE-1] OF CHAR;
Chars: CARDINAL;
NLines: CARDINAL;
Junk: FileIOStatus;
BEGIN
IF OpenFile(FileName,pFileIO) = Success THEN
NLines := 1;
WHILE NOT EOFFile(pFileIO) DO
Chars := GetLine(pFileIO,Line);
IF findTarget(TargetString,Line) THEN
putLine(FileName,NLines,Line);
END;
INC(NLines);
END;
Junk := CloseFile(pFileIO)
END
END MatchLines;
BEGIN
nArgc := Argc();
IF nArgc < 1 THEN
Usage();
HALT
END;
Argv(0,Target);
FileNumber := 1;
WHILE FileNumber < nArgc DO
Argv(FileNumber,FileMatch);
pList := MakeFileList(FileMatch);
WHILE pList # NIL DO
GetFileName(pList,FileName);
MatchLines(FileName,Target);
pList := GetNextFile(pList)
END;
INC(FileNumber)
END
END Find.
これで、FileSearchモジュール内部のデータ構造をFindが知る必要がなくなりました。





最近のコメント