PDPリカバリ11/04。 TU60テープステーション

古い興味深い機械の修復に関する記事の翻訳の継続。 最初の部分では、メインユニットボードをセットアップします。 たくさんの重い写真。 斜体は私のコメントです。

TU60テープドライブおよびTA11コントローラー

70年代、DECは、さまざまなシンプルなオーディオテープに基づいた、パンチテープの簡単な代替品を作成しました。 TU60は2つのストリーマーユニットを収容します。 50メートルのテープは最大100Kbを保存できます。







すべてのドライブロジックは2つの6ピンボードに含まれています（ これについては前に書きましたが、統合は良好です ）。







上面図では、モーターを制御し、磁気ヘッドからデータを読み取るアナログロジックを備えたボードを見ることができます。 従来のオーディオカセットとは異なり、TU60ドライブはテンションドラムを使用してテープ速度を制御しません。 代わりに、2つの独立したモーターが使用されます。 1つは、カセットを巻き戻し、張力をかけたままにするためのものです。 2つ目は、サーボによって駆動され、テープを前方に引っ張ります（ 実際、これは計画の地獄です。カセットが再生中または一時停止しているとき、最初のモーターもオンになります。たとえば、1つは100回転を巻き戻そうとし、2つ目は-そして、より強力なものが勝ちますが、もちろん、磁気テープはあまり好きではないので、このステーションを長時間オンにしておくことはお勧めできません。 ） 2番目のモーターの回転速度は一定です（ テープを読み取るときに一定であると完全に正確に言われているわけではありませんが、同じです！速度はタスクによって異なります。たとえば、テープがアイドルのとき、このモーターは最初の逆モーターと組み合わせて張力を与え、ブローチ加工時よりも速度が遅くなります ）、テープのビットレートも同じであるため、テープの全長にわたって情報密度が変化します。 TU60は、マンチェスターコードを使用してデータをエンコードします。



TA11コントローラモジュールは、4ピンM7892 Unibusボードで表されます（ 前の記事で1つのボードの異なる名前についても書きました ）。







コントローラーは、2つのレジスターの単純なインターフェースを提供します：コマンドステータス（ 頻繁に練習しても、1つの形式で読み取り用のレジスターを与え、もう1つの形式で書き込みを受け入れます。ここではすべてが異なります。これは全体的なレジスターですが、1つのフィールドは読み取り専用です他は書き込み専用ですが、読み取り/書き込みが混在しています。 ）、0177500で使用可能、0177502にデータバッファーがあります。ボードはTU60とPDP-11の間の仲介者であるだけでなく、追加のロジック（作業のチェーン）も含みます。割り込みやアドレスデコーダ（レジスへの参照をキャッチする必要があります フレーム）。



このデバイスで遊んでいると、すぐに問題に遭遇しました。 巻き戻しボタンは正常に機能するように見えました。 しかし、その後、突然、彼女は故障しました。 モーターの軸とカセットを接続する三角形の機構が軸から外れることは明らかでした。 図面によれば、＃2-56 1/8 "（ インチサイズ ）の止めネジがあるはずです。しかし、それはそこにはありませんでした。そして、それがどのように消えるのかは明確ではありませんでした。2番目のドライブにも同じ問題がありました。スウェーデンでは、メトリックシステムを使用しているためです。）私はより詳細に図を見ると、下の三角ヒッチに「止めネジ」の代わりに「ロクタイト」という碑文があります。いずれにせよ、私は接着剤を買いました 素晴らしい！



ただし、MaindecのZTAA診断テストは失敗しました。 私が最初に発見した問題は、制御ボードにあるDEC8881ドライバーで、EOTおよびBOT信号の通過を妨げていました。 私はそれを7439に交換しました。これはどこか中国で3ドル/個で購入しました。 興味深いのは、DEC8881のはんだ付けを解除したとき、下から7439というラベルが付けられていたことです！ その後、診断は2番目のストリーマーで行われ始めましたが、最初のストリーマーでは行われませんでした。 前進駆動はまったく機能しませんでした。 段階的に、障害のあるオープンコレクタードライバー75452を追跡しました。最後に、両方のドライブがZTAAを通過しました。 しかし、ZTABではありません...



テープにデータを書き込むときに何が起こるかを調べるために、テープ全体で0〜255のバイトシーケンスを連続して書き込む小さなアセンブラープログラムを作成しました。 プログラムは機能したので、テープからデータを読み取るように修正しました。 ロジックアナライザーをデータバッファーに接続すると、バイト00、01、02、...の一定のストリームが得られました。FD、FE、FF、00、01。

CAPS-11を起動します

CAPS-11オペレーティングシステムでテープイメージを取得しました。 ブートカセットには、CAPS-11 OS自体の初期ロードを提供するCTLOAD.SYSファイルが含まれていました。 たぶん、「オペレーティングシステム」は大声で言っているかもしれませんが、CAPS-11はファイルをテープにロードおよび保存する機能を備えたかなり単純なコマンドラインパーサーです。 システム自体はCAPS11.S8Kファイル内にあり、8キロメモリの環境で動作するようにリンクされていました（ PDPのメモリはプロセッサワードで測定されました。ちなみに、8進数システムは非常によく使用されました。 。 このOSの起動プロセスは非常に複雑です。 ブート領域（01000にある）はCBOOTと呼ばれます。 CTLOAD.SYSファイルの最初の32バイト（テープの最初のバイト）をスキップします。 次に、次の128バイトをメモリのアドレス0に読み込みます。CTLOAD.SYSのこの部分はPRELDRと呼ばれます。 PRELDRは使用可能なメモリのサイズを見つけ、すべてのCTLOAD.SYSを可能な限り高いアドレスのメモリにロードします。 ロードユニットにはCABLDRとCBOOT（ミラー）が含まれています。 CABLDRはカセットアブソリュートローダーですが、名前にもかかわらず、読み取り可能なファイルの形式はパンチテープの場合とまったく同じです。 したがって、CAPS11.S8Kにはパンチテープの形式があり、PDP11GUIを介して簡単にダウンロードできます（ このプログラムについては、前の記事を参照してください ）。 ただし、CABLDRはプログラマのコンソールによって提供されるスイッチレジスタを使用して、何をどのようにロードするかを決定するため（たとえば、このレジスタでシステムリベースアドレスを設定し、ユーザーアドレスにロードできます ）、いいえ、CABLDRは存在しないメモリを除いてマシンを停止します。



021510の開始アドレスでPDP11GUIを使用すると、CAPS-11プロンプトを表示できます。 70年代初頭からのシステムは2014年に開始されました。40年：







間違いなく、TU60はあまりうまく機能しません。

ベアシステムでのCコードの実行

TU60の問題に対処するには、記録された一連の操作を目的の順序で繰り返すだけのこのデバイスが必要です。 残念ながら、XXDPでの診断の作業はまったく予測できません。 読み取り操作と書き込み操作の両方で同じエラーコードを出力できます。 少なくとも、何が間違っているのかを特定することはできません。 さらに、ロジックアナライザーを使用すると、同じ測定を何度も実行できますが、研究のテストポイントをわずかに変更するだけです。 先に進むための最良の方法は、独自の簡単なテストプログラムを書くことだと決めました。 それ以前は、データをテープに読み書きする小さなアセンブラーコードを書きました。 しかし、PDP-11の経験豊富なアセンブラープログラマーではないため、コードの量がわずかに増えたとしても、ますます多くのデバッグ作業が必要になりました。 私はCが大好きです。



Cプログラムを作成するには何が必要ですか？ もちろん、クロスコンパイラーです！ ダイアン・ナイサスのページに触発されました。 GCC 4.8.2とともにBinutils 2.24をダウンロードしてコンパイルしました。



Binutils：

src/configure --target=pdp11-aout --disable-nls make all sudo make install
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GCC：

 src/configure --target=pdp11-aout --disable-nls --without-headers --enable-languages=c make all-gcc sudo make install-gcc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、CRTのエントリポイントであるcrt0.sが必要です。 私はちょうど働いた最小限のバージョンを書いた：

  .text .globl _main, ___main, _start _start: mov $400,sp jsr pc, _main halt ___main: rts pc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フォーマットされた行の出力は非常に有用なものなので、 組み込み開発用の小さなprintf実装を検索して見つけました。 ライブラリをコンパイルしてリンクしようとすると、多くの関数が見つかりませんでしたというメッセージを受け取りました-___ mulhi3、___ udivhi3など。 関数は、ネイティブPDP-11アセンブラー命令の代わりにgccによって使用されました。 乗算、除算、および残りの計算を実行するこれらの単純な関数の独自のバージョンを作成する必要がありました。



現在、PDP-11 / 10と互換性のある出力ファイルの作成に使用される-m10フラグを使用したコンパイル中に、短から長に変換するコードの生成中にコンパイラがクラッシュしました。 私が見つけた唯一の解決策は、PDP-11 / 40用にコンパイルし、SXTやASHCなど、PDP-11 / 04でサポートされていない命令を手動で置き換えることでした。



その後、私は本当のHello Worldを書く準備ができました。

 pdp11-aout-gcc -m10 -Ttext 1000 -msoft-float -nostartfiles -nodefaultlibs -nostdlib crt0.s printf.c test.c divmulmod.s pdp11-aout-objcopy -O binary a.out hello.dmp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードをアドレス0x1000または010000にリベースする必要があることをリンカーに通知し、objdumpを使用してオブジェクトをクリーンなバイナリファイルに変換しました。



最初に、実際のハードウェアをオンにする前に、このファイルをE11エミュレーターで実行しようとしました。 ただし、実際のマシンでPDP11GUIを使用して起動した場合のスクリーンショットは次のとおりです。







いいね！ フォーマットされた出力は正常に機能します。 乗算、除算、および剰余の取得も正しい結果になります（まあ、実際には、実際にはそうではありません。剰余を取得する機能には、修正しなければならないバグが含まれていることがわかりました）。 これで、古いTU60をロードするCテストプログラムを簡単に作成できました。 最後に、シリアルポートを介してファイルを読み取り、TU60にファイルを送信するプログラムを作成して、ブートカセットを作成できると思います。 いずれにせよ、CTLOAD.SYS内でCABLDRにパッチを適用して、スイッチレジスタを読み取ろうとしないようにします。これにより、例外が必ずスローされます。 （マシンにはプログラミングコンソールがありません）。

TU60EXERCISER

TU60EXERCISERという小さなプログラムを書くのに数時間費やしました。







これで、標準のZTA **プログラムを使用するよりも簡単な方法で、ドライブに対する操作を実行できます。 READコマンドをテストすると、オープンコレクタードライバーDEC8881（ これは以前に交換されたものではなく、別のDEC8881です）に問題が見つかりました。 これは 、ロジックアナライザーをTU60データバッファーに直接接続したときに気付かなかったものです。 問題は、CRC生成、または逆にCRC検証が失敗することでした。 データを正しく読み取っていた場合でも、データを読み取るときに常にCRCエラーが発生しました。



TU60EXERCISER'aのソースコードはこちらにあります 。

CRCの操作ロジックのエラーを検索します

以下は、テープに「AB」文字を書き込むとどうなるかを示す4枚の写真で、16ビットのチェックサムが生成されます。 データのLSBが最初に書き込まれ、WRITED信号がアクティブLowレベルに設定されます。



重要な点は、CRCは、ビット15、13、および0の入力信号がXORゲートを通過するフィードバック付きのシフトレジスタによって生成されることです。







エラーは明らかですか？ 私はすぐに彼女に気付きませんでしたが、数時間後に再び写真を調べて見つけました！



ビット5は高レベルでスタックしています。 しかし、常にではありませんが、鋭い目をした同志がどのように私を修正することができます。 最初は、すべてのビットがゼロです。 そのとおりですが、クリア信号を受信したという事実により、シフトレジスタ全体がリセット状態になります（ 他の多くの例と同様に8271にはクリア状態ピンがあります ）。 この場合、出力は正しいですが、データが連続してシフトレジスタに入力されると、誤った結果が返されます。 常に1シフトされます。 この要素は、Texas Instruments SN74179と同様のSignetics N8271チップによって実装されます。



ブルガリアから新しいものを注文しました（！）。

一歩先に2つ（3つ？）戻る

いくつかの失敗が待っていました。 最終的にブルガリアから74179を入手してはんだ付けし、適切なエミュレーター設定でTU60EXERCISERプログラムをE11でテストした後、カセットが故障し始めました。 これは、ヘッドとテープの間の摩擦が非常に大きいため、ストリーマーがそれらを正しく巻き戻すことができないという事実に現れました。 さらに、テープの断続的な移動のために、ドライブが何かを読み書きできない状況が発生しました。



これは、古いカセットの一般的な問題であることが判明しました。 Deoxit D5を手元に持っていませんでした（ 参考文献では、電気機械化合物用の特別な潤滑剤が使用されていました ）。 CRCからシリコンスプレーを試しましたが、目立った効果はありませんでした。



したがって、新しいテープを探す必要があります。 はんだごてを使用して、標準のオーディオカセットを変換しようとしました。 何らかの方法でこれは機能しましたが、何らかの理由で、巻き戻しがテープの先頭に達したことが検出されないことがありました。 ストリーマーは高速で巻き戻しを続けました。



しかし、それにもかかわらず、私はドイツのEbayで、1ユーロで熱重合体から10個のVerbatimカセットを販売していた男を見つけました。



それらが到着したとき、私はすぐにそれらをテストするために急いで行きましたが、コンピューターはもはや私にコンソールエミュレーターのコマンドラインを与えなかったことが判明しました。 どうした 論理アナライザーを接続すると、83行目の「mov」命令を実行しようとした後、マシンが停止することがわかりました。

  77 165046 005503 adc r3 ; R3=000000 C=1 78 165050 000303 swab r3 ; R3=000000 C=0 79 165052 001377 bne . ; br . if FAIL 80 81 ; ----------------------------------------- 82 83 165054 012702 165000 T2: mov #data0,r2 ; R2=165000 84 165060 011203 mov (r2),r3 ; R2=165000 R3=165000
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プローブをマイクロアドレスバスに接続すると、サンプリングステップの後、プロセッサが62ではなくアドレス60のマイクロ命令にジャンプすることが示されました（ソースモード2ハンドラー（ 命令をデコードする場合、8オペランドアドレッシングモード、laレジスタ、即値、ここでは、何らかの理由で、モード2ではなくモード0が考慮されました。モード自体は命令で直接エンコードされます。 E88は、入力に関係なく出力が常に1であるため、機能しないようです。 しかし、E77がマイクロアドレスバスを制御するため、E77にも問題がある可能性があります。 いずれにせよ、私は7427も74H01も持っていません。 スウェーデンのバディコレクターから7,427人がチェックを受けました。



しかし、このチップは準備中ですが、時間を無駄にしないために、予備のプロセッサボードをテストに使用できます。



ZTAA診断を使用して新しいテープのチェックを開始しましたが、これは完全に完了しました。 次に、CRCチェックを修正したため、ZTABを起動しましたが、これも成功するはずです。 私はテストを開始し、半時間歩いて行きました。 私が戻ったとき、ストリーマーによって作られた音は異なり、異常であり、コンソールは無限のエラーの山でいっぱいでした。 2番目のドライブは非常にゆっくりと回転しました。 スピンドルのゴムまたはプラスチックが、ある種のアモルファス接着剤に変わったことがわかりました。







このゴムバンドの代替品を探していましたが、レースアップレースアップに合うものは見つかりませんでした。 2層の自転車用タイヤチューブを試しました。 このタイプのゴムが十分柔らかいかどうかはわかりませんでした。 しかし、いずれにせよ、スピンドルホイールにゴムを貼り付けるには、良い接着剤を使用する必要がありました。接着剤が悪いと、ガムがすぐに飛んでしまうからです。 2番目の問題は、自転車の部屋の厚さがカット円全体で一定ではないことでした。 干渉する場合としない場合があります。 見てみましょう。



私は周りを回り、配管工に適切なものがあるかどうか尋ねましたが、残念ながら、彼らは私を助けることができませんでした。

新しいゴム製スピンドルパッド

ちなみに、その瞬間、E88の位置でチップを交換するために7427を受け取りましたが、プロセッサは機能しました！ スウェーデンの電子フォーラムを通じて、スピンドルのゴムを送ってくれた人に連絡しました。 古いものを取り除き、新しいものを接着剤で貼り付けることができました。



現在、ほとんどの診断は両方のドライブを通過しますが、ZTAEを除き、特別なものはチェックされませんか？





次の質問は、適切な媒体を選択することでした。 12月のオリジナルテープは2本しかありませんでした。 後に、モロッコの男からいくつかのNCRテープを受け取りました。 どうやら、彼らはすべてのグリースが蒸発したため、砂漠に長い間保管されていたようです。 ドイツから来た男性の逐語的カセットはかなり見栄えが良い。 泡のようなもので作られたクランプ装置には問題がありましたが、時間が経つにつれて摩耗します。 最後に、ほとんど中断することなくクラッシュするマクセルカセットがあります。 テープはドライブによって生じた緊張に耐えることができないようで、ほんの数回巻き戻しただけで壊れます（ ちなみに、先ほど書きました ）。







また、従来のオーディオカセットを変換しようとしましたが、成功の度合いはさまざまです。 一部は機能し、一部は機能しなかった。



次のステップは、CAPS-11をテープに記録して実行することです！ TU60EXERCISERを少し改良するだけです。

最後にテープからロード

TU60EXERCISER（現在は60toolsに名前が変更されました）を数回デバッグした後、テープにデータを書き込むことができるオプションがついに得られました。 さて、PDP-11はカセットから起動するのだろうか？



コンソールエミュレータで「CT」と入力した後、ストリーマーは最初に短時間カセットを回しましたが、その後停止しました。 CAPS-11のマニュアルを読み直し始めたところ、次のことに気付きました。

PRELDRは、システムテープの最初のファイルの最初のエントリである必要があります。 このプリローダーは、CBOOT Loader Formatに従って書かれた小さなプログラムです。CBOOTLoader Formatは、メモリのサイズを決定し、後続のプログラムを上位メモリアドレスにロードするのに十分なほど高度です。 CBOOTはアドレス0のメモリにリンクし、自動的に起動します。 このブート段階のCAPS-11メモリカードは、図E-3にメモリマップ＃2として示されています。

PRELDRは、スキームによって判断されるCBOOTが01000にあるという事実に依存していますか？ もちろん、ROMから起動します。



編集：問題の本当の原因は、仲間のコレクターのおかげで見つかりました：CBOOTは、TA11 CSR（ ストリーマーコントローラーのコマンドステータスレジスタ ）をR0（ ユーザープロセッサレジスタ ）に配置し、M9312 CT（ M9312はコンソールエミュレーター、CTはこのエミュレーターのコマンドですが、同時に、これはテープからのブートコードを含むEPROMチップの名前です。コマンドはこのEPROMのコードのみを起動しますが、システムの起動時に自動的に起動を試みます。 ）ロード時に、TA1 CSRをR1（およびR0のストリーマー番号）に入力します。 PRELDRは、レジスタTA11の値をR0で正確に見ることを期待しています。 CT-ROMから直接起動できるようにPRELDRにパッチを適用する必要があります。



E11を使用してソースからCBOOTを構築し、結果をCBOOT.BINファイルに書き込みました 。 その後、pdp11guiを介してメモリにロードし、アドレス01000から起動しました。はい！ カセットは約30分間再生を開始し、「。」記号が1つ現れました。 CAPS-11を起動しました！

 .DI -- CTLOAP SYS 19-FEB-14 CAPS11 S8K 25-NOV-13 DEMO PAL 25-NOV-13 EDIT SLG 25-NOV-13 LINK SRU 25-NOV-13 ODT SLG 25-NOV-13 PAL SRU 25-NOV-13 PIP SRU 25-NOV-13 ?NO SENTINEL FILE ?SYNTAX ERROR .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私のプログラムは、テープに書き込むために、最後のファイルになるはずの末尾ファイルを書き込みませんでした。 しかし、それはそのように働きました！ CTLOAP.SYSは、パッチが適用されたCTLOAD.SYSであり、スイッチレジスタへのすべてのアクセスが削除されているため、プログラムはオペレーターコンソールのみを備えたマシンでも動作します。

古いカセットの考古学

まず、CT EPROMからM9312を直接起動するようにCTLOAD.SYSにパッチを適用しました。これは非常に便利です。 コマンドを入力するとき、またはブートローダーのファイル（ 9600bps、これはすべて悲しい ）をアップロードするとき、これ以上の悪用はありません。 INITトグルスイッチをオンにすると、ストリーマーが起動します。 素晴らしい。 PRELDRを変更する必要があるだけでなく、CABLDRの腸のレジスタR0の初期化をスキップするために、BR命令（ 無条件のショートジャンプ、-128 .. + 127 ）も追加する必要があることが判明しました。 誰かがそれを必要とするなら、ここにパッチを当てたバージョンがあります。



CAPS-11をロードした後、これら2つの古いDECカセットに実際に何が保存されているのか疑問に思いました。 そのうちの1つの写真が上にあり、「S LMS 2 KOP」とマークされています。 「KOP」は「KOPIA」、コピーを意味する場合があります。 しかし、それ以外は、残りのキャラクターの意味がわかりません。 いくつかのファイルが含まれています。

 010000 051415 177714 000002 @CT CAPS-11 V01-02 .DA 27-MAR-14 .DI CT1: 27-MAR-14 CTLOAD SYS 07-JAN-75 CAPS11 S8K 07-JAN-75 PIP SRU 07-JAN-75 EDIT SLG 07-JAN-75 LINK SRU 07-JAN-75 ODT SLG 07-JAN-75 PAL SRU 07-JAN-75 BASIC LDA 07-JAN-75 .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CAPS-11システムでは、カセットの日付は1975年1月です。 ほぼ40年前のファイル。 コピーを作成し、パッチを適用したブートローダーを使用して起動しました。 彼女は始めました。 しかし、コマンドラインはありませんでした。 ソフトウェアが私のもの以外の異なるバージョンのハードウェア用に構成されている可能性があります。



カートリッジの内容を取り出すのは楽しいでしょう。 tu60toolsの作業を続けました。 繰り返しますが、ベアメタルで実行する場合の長いデバッグ。 ポインターに問題がある場合、人目を引くスタックトレースはありません。 最後に、TU60readはカセットからファイルを読み取る準備ができていたので、うまくいったようです。 少なくとも彼女は、私がテープに記録したファイルを正しく読んだ。 以前に作成したコピーカセットに使用し、次のファイルを受け取りました。



CTLOAD.SYS

CAPS11.S8K

PIP.SRU

EDIT.SLG

LINK.SRU

ODT.SLG

PAL.SRU

BASIC.LDA



CTLOAD.SYSバイナリを調べました。 1024の代わりに896バイト（7ブロック）かかりますが、完全に見えます。 分解すると、ほとんどのコードがCAPS-11に付属のCTLOAD.SYSと同一であることがわかります。



BASIC.LDAは、BASICを使用したパンチテープのコピーのようなものです。 このバイナリで文字列を実行すると、「PDP-11 BASIC、VERSION 007A」が取得されました。 同様に、「CAPS11.S8K」の場合、「CAPS-11 V01-02」となります。 したがって、このテープはオリジナルとわずかに異なるだけだと思います。



その後、2番目のカセットについて同じ調査を試みましたが、その上のファイルシステムが破損していました。 私はPDP-8の次のコードのみを掘り下げることができました。





わかった マシンが正常に起動したので、このPDP-11回復プロジェクトの最終段階に進みます。LA30Decwriterを再起動し、PDP-11とともに実行します。



記事の第3部では、LA30 Decwriterターミナルを修正します。