アカウント名:
パスワード:
図書館の書庫に大量に眠るフロッピー付録書籍あんな時代が懐かしい
『読み取り装置』も問題ですが、『データを入れる器』(=メディア)自体の寿命も気にはなりますよねぇ
20年前のCマガジンの付録FDとか保存してあるんですが、メディア不良で読み取れないディスクがけっこうな割合で・・・# まぁ、雑誌の付録くらいならあきらめもつきますけどね。
先日、Windows上にPC98エミュレータで箱庭を作って遊んだんですけど、一太郎(Ver4)と花子そのものはサルベージできたのに、肝心のジャストウィンドウのFDがメディア不良で読み出せなくて結局、太郎も花子も使えずorz
現行で一番、永続性という意味で強いメディアってなんなんでしょう?CD-Rでない、プレス版のCDですかねぇ??メディア自体の強度プラス読取装置がしばらく持ちそう、って意味で。
アナログメディアでも、30年モノ(^^;のカセットテープとかビデオテープとかいっぱい抱え込んでるんですけど、データ劣化が激しくてねぇ・・・
最新のストレージに定期的にコピーし続けるのが最適解かと。
>ハッシュ関数での入力ミスチェックなんていく技術もなく、
チェックサム(広義ではMD5ハッシュなんかも含む用語になってますが、ここでは単純加算の意味)くらいは付いていましたが、ひょっとして私が若造なダケですか?(^^;;
>あの当時の雑誌印刷ってのは0と8とBが区別しづらかったですね
『こんなコトもあろうかと』次のようなプログラムを自作したことがありますバイナリtoモンキーコンバータ。 [itscom.net]説明ページにはこう書いてありました。|バイナリファイルを猿の鳴き声に 変換するジョークソフト。|デコーダ機能はありません。Base64のしくみを理解するのに役立つかも
ちなみにunicodeなんて考慮以前の時代のシロモノなんで、日本語文字が2バイト前提(てか、ほぼSJIS限定)で書かれてますけど、ご容赦を(^^;
# fishとどちらが古いか知りませんが、当時fishの存在は知らずに作ったブツです
>紙という媒体の信頼性(場合によって千年以上もつ)壁画や石板だと万年単位での保存実績がありそうですが・・・(をい)
和紙と墨のタッグは最強だよ!とくに和紙の強さは驚愕もの。
しかも,多湿の日本ですでに10^3年オーダの保存実績あり。
ただし
などに注意。とくに後者は,2次元バーコードにはあまり向かないかも…
比較的後期の話ですが、Oh!MZ のダンプリストには、チェックサムの他に、128バイトブロック単位でのCRCが付いてました。元々、縦サム・横サム・ブロックサムの構成だったのですが、ある時期(たぶん1986年ぐらい(入力ツールMACINTO-Cが1987年1月) [retropc.net])から右下の、横サムの列、縦サムの行の交わる部分が、ブロック単位のチェックサムから、16進4桁のCRCの表示に変更になり、入力ミスでCRCまで一致する可能性はかなり低いので、なかなか便利でした。
私は自作の入力ツールで、・テンキーにA-Fもバインド・画面は一切見ずにダンプリストだけを見て入力、・ボイスボードでチェックサムなどを発声、で入力してましたが、慣れると1ページ(128バイト×17ブロックぐらい)を5分弱で入力できたので、ダンプリストの入力も全然苦じゃなかったですね。
チェックサムは合ってるけどCRCがずれてる時は、どこが間違えているか目視で探すのはすっぱり諦めてブロック丸ごと入力しなおし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
「付録のフロッピーに収録」 (スコア:0)
図書館の書庫に大量に眠るフロッピー付録書籍
あんな時代が懐かしい
Re: (スコア:0)
「もう読めるドライブがない!」
という日も間近。
3.5inch FDDはまだ会社にあるが、5inch FDDなんて見あたらない。
家では、3.5inchドライブもコレクションとしてのQuadra700くらいなので、
読めるかどうか分からん。
Re: (スコア:1)
『読み取り装置』も問題ですが、『データを入れる器』(=メディア)自体の寿命も
気にはなりますよねぇ
20年前のCマガジンの付録FDとか保存してあるんですが、メディア不良で読み取れない
ディスクがけっこうな割合で・・・
# まぁ、雑誌の付録くらいならあきらめもつきますけどね。
先日、Windows上にPC98エミュレータで箱庭を作って遊んだんですけど、
一太郎(Ver4)と花子そのものはサルベージできたのに、肝心のジャストウィンドウのFDが
メディア不良で読み出せなくて結局、太郎も花子も使えずorz
現行で一番、永続性という意味で強いメディアってなんなんでしょう?
CD-Rでない、プレス版のCDですかねぇ??
メディア自体の強度プラス読取装置がしばらく持ちそう、って意味で。
アナログメディアでも、30年モノ(^^;のカセットテープとかビデオテープとか
いっぱい抱え込んでるんですけど、データ劣化が激しくてねぇ・・・
♪潔くカッコよく生きてゆこう
Re: (スコア:2, すばらしい洞察)
最新のストレージに定期的にコピーし続けるのが最適解かと。
Re: (スコア:2, 興味深い)
使いたい時は、もちろんそれを見ながら打ち込んでください
Re:「付録のフロッピーに収録」 (スコア:0)
何が言いたかったかというと、紙という媒体の信頼性(場合によって千年以上もつ)からすれば、データを紙に墨で記録というのは案外捨てたもんじゃない(紙と墨の品質は吟味するとして)。で、ヒトの目が読まなくても、例えば2次元バーコード式に機械読み取りで、単位面積あたりの記録容量を上げてもいい。工夫の余地はあれど、紙に記録されたデータというのは、技術の進歩(退歩)とは無関係に保存性があるということです。
Re:「付録のフロッピーに収録」 (スコア:1)
>ハッシュ関数での入力ミスチェックなんていく技術もなく、
チェックサム(広義ではMD5ハッシュなんかも含む用語になってますが、
ここでは単純加算の意味)くらいは付いていましたが、ひょっとして私が若造な
ダケですか?(^^;;
>あの当時の雑誌印刷ってのは0と8とBが区別しづらかったですね
『こんなコトもあろうかと』次のようなプログラムを自作したことがあります
バイナリtoモンキーコンバータ。 [itscom.net]
説明ページにはこう書いてありました。
|バイナリファイルを猿の鳴き声に 変換するジョークソフト。
|デコーダ機能はありません。Base64のしくみを理解するのに役立つかも
ちなみにunicodeなんて考慮以前の時代のシロモノなんで、日本語文字が2バイト
前提(てか、ほぼSJIS限定)で書かれてますけど、ご容赦を(^^;
# fishとどちらが古いか知りませんが、当時fishの存在は知らずに作ったブツです
>紙という媒体の信頼性(場合によって千年以上もつ)
壁画や石板だと万年単位での保存実績がありそうですが・・・(をい)
♪潔くカッコよく生きてゆこう
Re:「付録のフロッピーに収録」 (スコア:1)
和紙と墨のタッグは最強だよ!
とくに和紙の強さは驚愕もの。
しかも,多湿の日本ですでに10^3年オーダの保存実績あり。
ただし
などに注意。
とくに後者は,2次元バーコードにはあまり向かないかも…
Re: (スコア:0)
I/O誌だとタテヨコチェックサムが標準でしたが、それとても次のような入力ミスは検出できません。
例)4箇所のデータを、次のとおり入力ミスしたとき・・・アドレス0のデータを-1、アドレス1のデータを+1、アドレス10のデータを+1、アドレス11のデータを-1
まして、他雑誌標準の、横だけ8(16)バイトずつ単純加算では、データの前後ミスが検出できないという・・・
Re:「付録のフロッピーに収録」 (スコア:1)
比較的後期の話ですが、Oh!MZ のダンプリストには、チェックサムの他に、128バイトブロック単位でのCRCが付いてました。
元々、縦サム・横サム・ブロックサムの構成だったのですが、ある時期(たぶん1986年ぐらい(入力ツールMACINTO-Cが1987年1月) [retropc.net])から
右下の、横サムの列、縦サムの行の交わる部分が、ブロック単位のチェックサムから、16進4桁のCRCの表示に変更になり、
入力ミスでCRCまで一致する可能性はかなり低いので、なかなか便利でした。
私は自作の入力ツールで、
・テンキーにA-Fもバインド
・画面は一切見ずにダンプリストだけを見て入力、
・ボイスボードでチェックサムなどを発声、
で入力してましたが、慣れると1ページ(128バイト×17ブロックぐらい)を5分弱で入力できたので、
ダンプリストの入力も全然苦じゃなかったですね。
チェックサムは合ってるけどCRCがずれてる時は、どこが間違えているか目視で探すのはすっぱり諦めてブロック丸ごと入力しなおし。