2017.9.15
前へ
次へ
ホームページトップへ戻る

マイコン独立大作戦
ROM/RAM/RTCボードの製作

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
WindowsパソコンにUSB接続して使う現行方式はそれなりに便利ではありますが、ときとしてWindows
のしがらみから開放されて、小さいながらも独立した一個のパソコンとして機能したいと思うこともあります。
独立大作戦の作戦その1はCRTインターフェースボードの製作です。
作戦その2はキーボードインターフェースです。
作戦その3は、SDカードインターフェースです。
作戦その4は、ROM/RAM/RTCボードです。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

[第26回]


●Windows7でまさかのエラーが?(2)

前回からの続きです。
前々回にSDカード上に作成した模擬的なLOGファイルをWindows7で開こうとしたところ「ファイルがみつかりません」と表示されてしまいました。
こういう想定外のメッセージを食らってしまいますと、しばし思考停止に陥ってしまいます。

プロパティで確認するとデータが0バイトと表示されています。
でもエクスプローラには2KBと表示されています。
そもそもエクスプローラにはちゃんと123456Wz.LOGというファイル名が表示されているのですから、おかしな話です。

このような一見するとわけがわからないようなエラー(?)の場合には、知識を総動員して、そこに隠された意味をさぐらなければなりません。
エクスプローラではちゃんと表示されているのに、データ本体にアクセスしようとすると、そこに行き着けない、というようなことがおきているのではないか?
しかしLOGディレクトリの123456Wz.LOGエントリ(ファイル名を記した32バイト)の部分にはバイト数もクラスタ番号もちゃんと書いてあります([第24回]参照)。
そこに間違いが無いことはしっかり確認しました。

それなのにWindows様が「読めない」とおっしゃってみえるということになりますと、私には(あるいはエクスプローラには)見えているのだけれど、Windowsではそのデータが開けない何かがある、と考えられます。
具体的にいうとディレクトリのファイル情報のどこかが壊れているとか?

おお。
ひょっとすると、そこか?
思いついたことを確認してみるために、LOGディレクトリのその部分をちょいと加工してみましたら。

ビンゴ!でありました。
プロパティにファイルサイズが表示されました。

そういうことだったのでした。
何をしたのか(そしてなぜなのか)おわかりになりますでしょうか?

SDカードをND80Z3.5に戻して、こういう作業を行いました。

>cm 8003
8003 00-
8004 02-03
8005 E0-03
8006 2A-
>jp 8000
>dm 8200,83ff
8200  2E 20 20 20 20 20 20 20-20 20 20 10 00 00 00 00  .          .....
8210  00 00 00 00 00 00 00 00-00 00 04 00 00 00 00 00  ................
8220  2E 2E 20 20 20 20 20 20-20 20 20 10 00 00 00 00  ..         .....
8230  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8240  31 32 33 34 35 36 37 30-4C 4F 47 20 00 00 00 00  12345670LOG ....
8250  00 00 00 00 00 00 00 00-00 00 40 01 00 00 00 00  ..........@.....
8260  31 32 33 34 35 36 37 4A-4C 4F 47 20 00 00 00 00  1234567JLOG ....
8270  00 00 00 00 00 00 00 00-00 00 41 01 00 04 00 00  ..........A.....
8280  31 32 33 34 35 36 37 5A-4C 4F 47 20 00 00 00 00  1234567ZLOG ....
8290  00 00 00 00 00 00 00 00-00 00 42 01 00 06 00 00  ..........B.....
82A0  31 32 33 34 35 36 37 6A-4C 4F 47 20 00 00 00 00  1234567jLOG ....
82B0  00 00 00 00 00 00 00 00-00 00 43 01 00 06 00 00  ..........C.....
82C0  31 32 33 34 35 36 37 7A-4C 4F 47 20 00 00 00 00  1234567zLOG ....
82D0  00 00 00 00 00 00 00 00-00 00 44 01 00 06 00 00  ..........D.....
82E0  31 32 33 34 35 36 47 7A-4C 4F 47 20 00 00 00 00  123456GzLOG ....
82F0  00 00 00 00 00 00 00 00-00 00 45 01 00 04 00 00  ..........E.....
8300  31 32 33 34 35 36 57 7A-4C 4F 47 20 00 00 00 00  123456WzLOG ....
8310  00 00 00 00 00 00 00 00-00 00 46 01 80 04 00 00  ..........F.....
8320  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8330  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8340  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8350  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8360  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8370  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8380  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8390  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
83A0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
83B0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
83C0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
83D0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
83E0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
83F0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
>cm 8307
8307 7A-5a
8308 4C-
>/ld sctwr.bin,8100
loading SCTWR.BIN ...0017(23)bytes loaded,from 8100 to 8116
>cm 8113
8113 70-90
8114 C3-
>cm 8103
8103 00-
8104 00-03
8105 00-03
8106 2A-

>jp 8100
>cm 8300
>jp 8000
>dm 8300,8330
8300  31 32 33 34 35 36 57 5A-4C 4F 47 20 00 00 00 00  123456WZLOG ....
8310  00 00 00 00 00 00 00 00-00 00 46 01 80 04 00 00  ..........F.....
8320  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
8330  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

最初にSCTRDプログラム(8000にロード)を実行してLOGディレクトリを確認しました。
ターゲットはLOGディレクトリの123456Wz.LOGのエントリです。
LOGディレクトリはSCTRDによってバッファアドレス8200〜83FFに読み込まれています。
123456Wz.LOGのエントリはアドレス8300〜831Fにあります。
その一部を書き換えます。
8307の7A(”z”)を5A(”Z”)に書き換えました。

そしてSCTWR(8100にロード)でバッファの中身をもとのLOGディレクトリセクタに上書きしました。
こういう細工がいとも簡単にできてしまうところが、ND80Z3.5のよいところです。
Windowsでそれをやろうとしたら大変でしょう。
念のためにSCTRDで、書き換わっていることを確認しました。
そういう作業をしたところ、さきほどの画面のようにWindows7で正しく認識してくれるようになりました。
つまり、ファイル名が123456Wz.LOGではだめで、123456WZ.LOGならOKということです。

そのわけは。

現在のFAT16システムよりもずっと以前、MSDOSの時代にはファイル名は8バイト+拡張子3バイトでした。
現在はもっと長い名前(〜255バイト)でも自由に使えます(long filename)。
それに加えて昔はファイル名に使える文字にも厳しい制限があって、数字と英大文字と一部の記号に限られていました。
名前の8文字は認識していたのですが、英大文字の制約についてはうっかりしておりました。
しかし文字型はともかくとして、8+3=11バイトしかないディレクトリエントリのスペースにどうやって最長255バイトものファイル名を置くことができるのでしょうか?

FAT16では昔の規格(8.3ルールなどといいます)との互換性を維持するために(それとおそらくはディレクトリエリアのサイズ、アクセス速度を考慮するために)ファイル名のところは昔と同じ11バイトのままになっています。
そこのところをクリアする仕組みとは?

確かどこかでちらりとお見せしたことがあったような。
「SDカードインターフェースの製作」[第31回]にありました。
これはFAT32の例なのですが。

8800  4F 48 41 59 4F 42 20 20-42 54 4B 20 00 B1 79 41  OHAYOB  BTK .アyA
8810  5D 49 5D 49 00 00 0D 74-31 3D 03 00 81 00 00 00  ]I]I...t1=......
8820  4F 48 41 59 4F 42 20 20-4C 53 54 20 00 B7 79 41  OHAYOB  LST .キyA
8830  5D 49 5D 49 00 00 0D 74-31 3D 04 00 42 0A 00 00  ]I]I...t1=..B...
8840  41 4F 00 48 00 41 00 59-00 4F 00 0F 00 91 62 00  AO.H.A.Y.O....b.
8850  2E 00 74 00 78 00 74 00-00 00 00 00 FF FF FF FF  ..t.x.t.........
8860  4F 48 41 59 4F 42 20 20-54 58 54 20 00 BF 79 41  OHAYOB  TXT .ソyA
8870  5D 49 5D 49 00 00 A2 56-F5 3C 05 00 A0 04 00 00  ]I]I..「V.<.....
8880  4F 48 41 59 4F 42 20 20-42 49 4E 20 00 C5 79 41  OHAYOB  BIN .ナyA
8890  5D 49 5D 49 00 00 0D 74-31 3D 06 00 7D 00 00 00  ]I]I...t1=..}...

ロングファイルネームの規則では、長さと同時に英大文字、小文字の区別もあわせて対象にしているようです。
バッファアドレス8860〜887Fにある「OHAYOB.TXT」というファイル名は、本当は「OHAYOb.txt」(b、txtが小文字)として作成したものです。
その本当の文字情報はひとつ上の8840〜885Fに置かれています。
全角文字も置けるように先頭の1バイトを除いて、2バイトに拡張したエリアにもとの文字が置かれていて、名前以外の情報(日付、データクラスタ番号、ファイルサイズなど)はありません。
そして先頭の1バイトで、ここがそういう特殊なエリアであることを示しています。
先頭の1バイトは01〜ではないかと思うのですが、ここでは41になっています。
FAT16とFAT32では違っているのかもしれません。
ま、そこは目下のところ、深追いする必要はありません。

とにかくFAT16ではファイル名として英小文字を使うときは昔の8.3ルールではなくて、上のようなルールを適用する、ということのようです。
そこで問題となりそうな英小文字の使用をやめて、英大文字にしたところ、上のほうで見ていただきましたように、正しく認識されるようになりました。

しかしそれでも疑問は残ります。
一部に英小文字を使ったとしても、サイズとしては8+3バイトに収まっているのでしたら、そのまますんなりと読んでくれてもよさそうなもの、という疑問です。
事実、同じように英小文字を使っている1234567j.LOGはこの通り、まともに認識されました。



1234567z.LOGもこの通りです。



でも123456Gz.LOGは駄目でした。



どうやら英大文字と小文字が混在すると、こけてしまうようです。
ま、Windows様は気まぐれでいらっしゃいますから、そんなところでありましょう。
とにかく小文字は使わないことにいたしましょう。

まともに認識できるようになった123456WZ.LOGをメモ帳で開きました。


テスト作成したファイルですから8ビットの全コード(00〜FF)を使っています。
文字としてまともに表示できないコードは文字化けしていますが、そうではないところはまともに表示されています。

これにて一件落着です。

ROM/RAM/RTCボードの製作[第26回]
2017.9.15upload

前へ
次へ
ホームページトップへ戻る