アカウント名:
パスワード:
SDカードは何度も非互換な規格変更を繰り返してるけど最初から将来を見越して8MBから1PBくらいまで一応使えるようにしたかったならどうするのが正解だっただろう?16BくらいのID(GUID)で指定できるSDカードチェンジャーのコマンドを用意して、システム用とデータ用にパーティションを2つに分けてもそれなりにきちんと動作するように設計しておく。規格変更時には当然ファイルシステムや通信規格の変更は当然必要だから許容するとして、仮想SDカードチェンジャーとして動作するようなチップを追加する。そうすれば昔夢にも思わなかった莫大な容量を昔の機器でも使えるというハッピーな可能性もあったかもしれない。アクセス速度が低速で莫大な容量があるってのが用途が限られて、なんか無圧縮音源や辞書や地図を入れたりしたような初期のCDなんかと似てる感じがするが。
「もしメモリモジュールに互換性があれば、今では無改造X68000に8GBメモリを積めてるのでは」みたいな話ですね
流石に32bitだから4GiBよりは無理じゃない?
68000のアドレスバスは24bitなので・・・・・・
そこはイロイロなマッピング手段があるでしょ。バンク切り替えしても良いし、セグメントレジスタ追加しても良い。
セグメントとオフセットかな。あるいはバンク切り替えかな。
そして最大ファイルサイズ2GBの呪縛で頓死かなw
SDカードは、レガシーを引きずりたくないタイミングで規格更新してるのが、成功のポイントに思えます。適度に古い機器を切り捨てるってことね。ファイルフォーマットも、exFATみたいなのが出てきてからじゃないと規格策定もできないし。
ちなみに、SDXCの128TBを使うSDカードは、今の容量増大ペースだと2055年に登場の模様。当面次の規格は気にしなくて良さそう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
前方互換性があるのは良いな (スコア:0)
SDカードは何度も非互換な規格変更を繰り返してるけど最初から将来を見越して8MBから1PBくらいまで一応使えるようにしたかったならどうするのが正解だっただろう?
16BくらいのID(GUID)で指定できるSDカードチェンジャーのコマンドを用意して、システム用とデータ用にパーティションを2つに分けてもそれなりにきちんと動作するように設計しておく。
規格変更時には当然ファイルシステムや通信規格の変更は当然必要だから許容するとして、仮想SDカードチェンジャーとして動作するようなチップを追加する。
そうすれば昔夢にも思わなかった莫大な容量を昔の機器でも使えるというハッピーな可能性もあったかもしれない。
アクセス速度が低速で莫大な容量があるってのが用途が限られて、なんか無圧縮音源や辞書や地図を入れたりしたような初期のCDなんかと似てる感じがするが。
Re: (スコア:0)
「もしメモリモジュールに互換性があれば、今では無改造X68000に8GBメモリを積めてるのでは」みたいな話ですね
Re:前方互換性があるのは良いな (スコア:1)
流石に32bitだから4GiBよりは無理じゃない?
Re: (スコア:0)
68000のアドレスバスは24bitなので・・・・・・
Re: (スコア:0)
そこはイロイロなマッピング手段があるでしょ。
バンク切り替えしても良いし、セグメントレジスタ追加しても良い。
Re: (スコア:0)
セグメントとオフセットかな。
あるいはバンク切り替えかな。
そして最大ファイルサイズ2GBの呪縛で頓死かなw
SDカードは、レガシーを引きずりたくないタイミングで規格更新してるのが、成功のポイントに思えます。
適度に古い機器を切り捨てるってことね。
ファイルフォーマットも、exFATみたいなのが出てきてからじゃないと規格策定もできないし。
ちなみに、SDXCの128TBを使うSDカードは、今の容量増大ペースだと2055年に登場の模様。
当面次の規格は気にしなくて良さそう。