パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

付録 CDならぬ、付録 SDカードつき書籍出現」記事へのコメント

  • 図書館の書庫に大量に眠るフロッピー付録書籍
    あんな時代が懐かしい

    • by Anonymous Coward
      イメージファイルに落としておいてくれないと、
      「もう読めるドライブがない!」
      という日も間近。

      3.5inch FDDはまだ会社にあるが、5inch FDDなんて見あたらない。
      家では、3.5inchドライブもコレクションとしてのQuadra700くらいなので、
      読めるかどうか分からん。
      • 『読み取り装置』も問題ですが、『データを入れる器』(=メディア)自体の寿命も
        気にはなりますよねぇ

        20年前のCマガジンの付録FDとか保存してあるんですが、メディア不良で読み取れない
        ディスクがけっこうな割合で・・・
        # まぁ、雑誌の付録くらいならあきらめもつきますけどね。

        先日、Windows上にPC98エミュレータで箱庭を作って遊んだんですけど、
        一太郎(Ver4)と花子そのものはサルベージできたのに、肝心のジャストウィンドウのFDが
        メディア不良で読み出せなくて結局、太郎も花子も使えずorz

        現行で一番、永続性という意味で強いメディアってなんなんでしょう?
        CD-Rでない、プレス版のCDですかねぇ??
        メディア自体の強度プラス読取装置がしばらく持ちそう、って意味で。

        アナログメディアでも、30年モノ(^^;のカセットテープとかビデオテープとか
        いっぱい抱え込んでるんですけど、データ劣化が激しくてねぇ・・・

        --
        ♪潔くカッコよく生きてゆこう
        • Re: (スコア:2, すばらしい洞察)

          最新のストレージに定期的にコピーし続けるのが最適解かと。

          • Re: (スコア:2, 興味深い)

            中身を16進でダンプして、紙に印刷しといた方がいいんじゃないかな。
            使いたい時は、もちろんそれを見ながら打ち込んでください
            • by Anonymous Coward
              16進ダンプを手入力世代なんですけど、あの当時の雑誌印刷ってのは0と8とBが区別しづらかったですね。ファイル圧縮なんていう技術もなく、ハッシュ関数での入力ミスチェックなんていく技術もなく、ただただ自分の目と手をフル回転だったという。あの当時のI/O誌でも、手入力の手間を省く工夫が記事になったりI/Oプラザに投稿されたりしてました。記憶では、印刷されたBASICのリストを読み取るOCRの自作記事があったかと。いうまでもなく読み取り誤り対策は手作業での修正なので、手間はかかるわけですが。

              何が言いたかったかというと、紙という媒体の信頼性(場合によって千年以上もつ)からすれば、データを紙に墨で記録というのは案外捨てたもんじゃない(紙と墨の品質は吟味するとして)。で、ヒトの目が読まなくても、例えば2次元バーコード式に機械読み取りで、単位面積あたりの記録容量を上げてもいい。工夫の余地はあれど、紙に記録されたデータというのは、技術の進歩(退歩)とは無関係に保存性があるということです。
              • >ハッシュ関数での入力ミスチェックなんていく技術もなく、

                チェックサム(広義ではMD5ハッシュなんかも含む用語になってますが、
                ここでは単純加算の意味)くらいは付いていましたが、ひょっとして私が若造な
                ダケですか?(^^;;

                >あの当時の雑誌印刷ってのは0と8とBが区別しづらかったですね

                『こんなコトもあろうかと』次のようなプログラムを自作したことがあります
                バイナリtoモンキーコンバータ。 [itscom.net]
                説明ページにはこう書いてありました。
                |バイナリファイルを猿の鳴き声に 変換するジョークソフト。
                |デコーダ機能はありません

                --
                ♪潔くカッコよく生きてゆこう
              • by Anonymous Coward on 2009年07月19日 12時37分 (#1607449)
                チェックサムは、ご指摘のとおり単純加算(の、下2桁)なもので、誤入力の検出には非力なのですね。
                I/O誌だとタテヨコチェックサムが標準でしたが、それとても次のような入力ミスは検出できません。

                例)4箇所のデータを、次のとおり入力ミスしたとき・・・アドレス0のデータを-1、アドレス1のデータを+1、アドレス10のデータを+1、アドレス11のデータを-1

                まして、他雑誌標準の、横だけ8(16)バイトずつ単純加算では、データの前後ミスが検出できないという・・・
                親コメント
              • 比較的後期の話ですが、Oh!MZ のダンプリストには、チェックサムの他に、128バイトブロック単位でのCRCが付いてました。
                元々、縦サム・横サム・ブロックサムの構成だったのですが、ある時期(たぶん1986年ぐらい(入力ツールMACINTO-Cが1987年1月) [retropc.net])から
                右下の、横サムの列、縦サムの行の交わる部分が、ブロック単位のチェックサムから、16進4桁のCRCの表示に変更になり、
                入力ミスでCRCまで一致する可能性はかなり低いので、なかなか便利でした。

                私は自作の入力ツールで、
                ・テンキーにA-Fもバインド
                ・画面は一切見ずにダンプリストだけを見て入力、
                ・ボイスボードでチェックサムなどを発声、
                で入力してましたが、慣れると1ページ(128バイト×17ブロックぐらい)を5分弱で入力できたので、
                ダンプリストの入力も全然苦じゃなかったですね。

                チェックサムは合ってるけどCRCがずれてる時は、どこが間違えているか目視で探すのはすっぱり諦めてブロック丸ごと入力しなおし。

                親コメント

日々是ハック也 -- あるハードコアバイナリアン

処理中...