MSX文字の調査その2

様々な協力を得て、次の環境で調査をすることができました。

MSX2+ Sony HB-F1XDJ
MSX2+ Sanyo Wavy PHC-70FD
MSXPLAYer

画像は紹介できませんので、結果だけ報告します。

全て、簡単なようにCALL KANJIのシフトJISでのみ確認しており、PUT KANJIや、I/Oポートを叩いての漢字ROM直接調査はしていません。

MSXPLAYerなんてのまで情報が来たので少々感激です。
そういえば1chipMSXなんてのが前に話にあった気がしたけど、今確認したら完売だった。漢字ROMはどうなっているのだろう。どこかのをライセンスで使っているのだと思うけれど。


あと、これ以降、見えてはいけない場所に見える漢字類を「亡霊」と呼ぶことにしておきます。


MSX2+ Sony HB-F1XDJ


第一水準、第二水準搭載

81xx‐85xxまでにある拡張文字の類は、全てパナと同様にありました。
85DEが5、85DF以降に第一水準が見えてしまう問題も、パナと同様です。

EBxxは、パナと違って新JISの記号類がありませんでした。EB40から、柄並蔽閉陛米…と第一水準42区の亡霊が見えました。その他、途中に縦棒2本や空白が見えます。
ECxx、EDxxも同様に漢字ROMの中身をそのまま出しているようで、FCFCまで全て漢字ROMが見えていました。

漢字ROMの構成はささの様のコメントにあるHBI-J1の画像が参考になりますが、やはり途中が空いているようです。
恐らく、HBI-J1と、ソニーMSXの内蔵は、同じ仕様と思われます。
末端の配列が中途半端で微妙ですが、アドレスバスの処理のどこかで手を抜いていて、亡霊が見えているのかもしれません。


MSX2+ Sanyo Wavy PHC-70FD


第一水準のみ搭載

81xx‐85xxまでにある拡張文字の類は、全てパナと同様にありました。
パナ、ソニー、三洋と共通するということは、このあたりはMSXの共通仕様なのかもしれません。
85DEが5、85DF以降に第一水準が見えてしまう問題も、パナと同様です。このあたりもMSXの共通仕様なのかもしれません。
第一水準のみなので、EBxx以降の動作は確認できませんでした。


MSXPLAYer


第一水準、第二水準搭載
雑誌に添付されたエミュレーターだそうです。現物は見たことがありません。

81xx、82xxにある拡張文字は、パナと同様でした。
83xxは若干違っており、αの前の「□二つ」とωの後の「メッシュ」が出てきませんでした。
84xxにある拡張文字は、パナと同様でした。
85xxの前半にある二重の文字もパナと同様で、後半に第一水準の亡霊が出るのも同様ですが若干動作が違い、間にいわゆる「豆腐」が出るのと、亜の直前が5ではなく空白になっています。
86xx‐88xxまでも同様に第一水準の亡霊が見えますが、10 20 30といった数字文字や、Fの変型文字はなく、空白になっています。

EBxx‐ECxxは、全て「豆腐」です。
EDxxは、EDDDまでが「豆腐」、EDDEが空白、EDDFから第二水準の亡霊「弌丐丕个…」となっています。以降、途中に2文字の空白があく、漢字ROMそのままなのも同様です。
こうして、FCFCまで第二水準の亡霊が続いていました。


結果


MSX2+のCALL KANJI処理部分はどのメーカーでも同じだと思うのですが、表示がずいぶんと違うのが興味深いですね。
基本となるソフトがマイクロソフトあたりから提供されて、各メーカーが独自に変更して搭載しているのかも知れませんし、ハードウェア仕様に合わせてマイクロソフトが微調整しているのかも知れませんし、ソフトウェアはそのまま、ハードウェアの都合でこうなっているのかも知れません。

あと、亡霊が見えてしまうのは、当時よく動作検証しなかったか、「まぁいいや」で済ませてしまったツケなのかもしれません。
MSXPLAYerですら、それは維持されています。


対応のために


機種名を指定させるのが最も良いのでしょうが、全機種名を網羅するわけには、さすがに行きません。
あと、松下/パナは、古いものも新しい物もどうやら同じ仕様ですし、他のメーカーも同様でしょう。変更する意味はないと思われるので。ということで、機種名を指定するメリットがあまりない。

従って、メーカーを指定するスタイルになると思われます。もし万一新旧があるようなら、あとで工夫することにしましょう。

SHIFT_JIS/MSX 汎用 (1,2)
SHIFT_JIS/MSX/1 汎用 (1)

SHIFT_JIS/MSX/PANA パナ (1,2)
SHIFT_JIS/MSX/PANA/1 パナ (1)
SHIFT_JIS/MSX/SONY ソニー (1,2)
SHIFT_JIS/MSX/SONY/1 ソニー (1)
SHIFT_JIS/MSX/SANYO/1 三洋 (1)
SHIFT_JIS/MSXPLAYER MSXPLAYer (1,2)

MSXPLAYERは、起動時にMSXのロゴが出てこないそうなので、MSXではないのかもしれません。
ので、MSXPLAYERとしておきましょう。MSX/MSXPLAYER というのも煩わしい気がしますので。

実質的に、PANA/1 = SONY/1 = SANYO/1 です。
別名として末尾に /2 を付けると無印と同じく動作します。SHIFT_JIS/MSX/2 = SHIFT_JIS/MSX



仕様


符号については、SJIS以外は考える必要がないので色々と楽ですね。

概ね、想定される仕様は、次の通りです。

汎用


・81xx 拡張文字対応
・82xx 拡張文字対応
・83xx 拡張文字に対応しない
・84xx 拡張文字対応
・85xx 拡張文字対応、亡霊文字未対応
・86xx 亡霊文字未対応、数字文字やFの変型文字に未対応
・87xx 亡霊文字未対応、数字文字やFの変型文字に未対応
・88xx 亡霊文字未対応、数字文字やFの変型文字に未対応
・第一水準、第二水準対応、漢字配列はJIS83(新JIS)対応
・EBxx‐FCxx 無効
第一水準のみの場合は、第二水準文字を無効とする

おおむねPUT KANJI相当になると思われます。
これを出力に使えば、殆どのMSX(の日本語表示モード)で読める文書が出て来るでしょう。


パナ


・81xx 拡張文字対応
・82xx 拡張文字対応
・83xx 拡張文字対応
・84xx 拡張文字対応
・85xx 拡張文字対応、亡霊対応(リードオンリー)
・86xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・87xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・88xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・第一水準、第二水準対応、漢字配列はJIS83(新JIS)対応
・EBxx 新JIS文字対応
・ECxx 拡張文字、絵文字類対応
・EDxx‐FCFC 亡霊対応(リードオンリー)

第一水準のみの場合は、第二水準文字を無効とする
化けて出る文字も、読み込みには対応する必要があるだろう


ソニー


・81xx 拡張文字対応
・82xx 拡張文字対応
・83xx 拡張文字対応
・84xx 拡張文字対応
・85xx 拡張文字対応、亡霊対応(リードオンリー)
・86xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・87xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・88xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・第一水準、第二水準対応、漢字配列はJIS83(新JIS)対応
・EBxx‐FCFC 亡霊対応(リードオンリー)

第一水準のみの場合は、第二水準文字を無効とする
化けて出る文字も、読み込みには対応する必要があるだろう


三洋


第一水準のみであるほかは、パナやソニーと同じ


MSXPLAYer


・81xx 拡張文字対応
・82xx 拡張文字対応
・83xx 拡張文字に対応しない
・84xx 拡張文字対応
・85xx 拡張文字対応、亡霊対応(リードオンリー)
・86xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・87xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・88xx 亡霊対応(リードオンリー)、数字文字やFの変型文字に対応
・第一水準、第二水準対応、漢字配列はJIS83(新JIS)対応
・EBxx‐ECxx 無効
・EDxx‐FCFC 亡霊対応(リードオンリー)



実装


拡張文字については、Unicodeとの変換表を用意して相互変換することになるでしょう。
Unicodeに無い文字もあるので、内部では専用バンクを用意して文字管理をすることになります。

MSXPLAYerで出て来る「豆腐」は、無効文字にするべきなのか、あるいは何かUnicode文字にマッピングするべきなのか。
横線、アキ、横線、アキ…という単純なパターンなのだが、Unicodeにはそのままのがない。U+2591 ░ LIGHT SHADEか、あるいはU+25A4 ▤ SQUARE WITH HORIZONTAL FILL あたりが、許容範囲かな、という気がします。


一番面倒なのは、たぶん亡霊への対応だと思います。

入力と出力を同じ符号にしたとして、亡霊について、その符号位置を保つ必要はあるのだろうか。謎だ。第一水準、第二水準の正しい符号位置に変換するのが最も実用的だろうとは思うのだけども。

←前

2009/11/27(金)00:18 |Comments(8) |Trackback(0)

文字 | コンピュータ関連 | コンピュータ | [編集]

▲ページトップ

コメント

1chip MSXのデコード結果はこんな感じです。
いわゆるjiskan16と呼ばれる系統のフォントです。

http://uaa.org.uk/gomitext/2008/20080622/1chipmsx.png

JIS第二水準の領域はゴミだらけですが、
MSXの定める、JIS第二水準の漢字ROMの有無を判定する方法で
きちんと蹴られるため、実用上の問題はありません。
JIS第一水準のみ実装された機械として扱えば良いはずです。


(おまけ)
VictorのHS-R6002という漢字ROMでの結果です。

http://uaa.org.uk/gomitext/2008/20080626/20080626.png

基本的にPanasonic系と同じですが、「唖」などいくつかの字形が変わっています。
2009/11/27(金)20:06 |ささのたかよし | URL |編集
▲ページトップ

ありがとうございます。

1chip MSXは、いま想定している、汎用の第一水準限定の集合に一致するようです。


HS-R6002は、一件JIS78風ですが、JIS83での字形の変更と追加4字に対応しているようです。
ただJIS83でなされた文字の入れ換え22組44文字がおこなわれていないように見えたので調べましたが、どうやら第一水準も第二水準も、旧字体となっているようで、同じ字が重複しているように見えました。
もう少し大きい画像を戴けると、研究や実装の役に立つのですが、難しいですよね。
2009/11/27(金)22:04 |miraicorp | URL |編集
▲ページトップ

原寸サイズでも、差分だけならおそらく問題なかろうということで
こういうものを作成してみました。

http://www.uaa.org.uk/gomitext/2008/20081019/20081019c.png

あの時代のパソコンやワープロに搭載されていた漢字ROMのフォントデータは、
そろそろ無償で公開すべき時期に来ていると個人的には感じています。
どこに働きかければ良いか全く見当は付きませんが…

日本語の場合、フォントの開発には多大な費用が掛かることは確かなのですが、
だからこそ、当時のパソコン(あるいはワープロ)文化を記す貴重な資料ともなります。
実際、今回のような文字コード変換ツールを作成する上で役に立っている訳ですし…

どうにかならないものか、どうにかできないものかと、日々歯痒さを感じています。

#MSX-Viewの方はもう少しお待ちください
2009/11/28(土)19:07 |ささのたかよし | URL |編集
▲ページトップ

ありがとうございます。眺めてみました。

JIS78→JIS83では、約300字について、字形が変更されたとされていますが、その対応がされていないか、していても中途半端な状態になっているのかもしれません(一応、どちらの字形でも包括範囲内とはされています)。
漢字については正確に数えてませんが90字少々に違いがあるようですね。

鱒 麺麵 頚頸 榊 鴎鷗 祷禱

といった字に違いが見いだされます。

第一水準のツボが「壺」の字形になってますね。
JIS83ではこの字が第二水準に移動し、代わりに「壷」が第一水準に移動する交換が行なわれましたが、この漢字ROMだと第一水準が「壺」です。しかし第二水準で特に違いがないとすると第二水準も「壺」なのでしょうか。重複と見られます。

「蠣」や「儘」がありますが、これもJIS83では蠣・儘は第二、蛎・侭が第一と交換になっている字です。第二水準に変化がないようなので、これも重複しているようです。

しかし同様に第一水準と第二水準で交換された「桧檜」については差分に出ていないので、JIS83に準じて交換されているのかもしれません。
2009/11/29(日)12:10 |miraicorp | URL |編集
▲ページトップ

遅くなってすみません。MSX-View(FS-A1GT内蔵ではなく、別売り)のフォントROMのデコード結果です。
単純にデコードしただけなので、半角文字も一緒に表示されています。

http://www.uaa.org.uk/gomitext/2009/20091130/view12.png (12x12)
http://www.uaa.org.uk/gomitext/2009/20091130/view8.png (12x8)

12×12ドット物はJIS第一/第二水準を実装していますが、第二水準はバグがあります。
12×8ドット物は、JIS第一水準のみです。

文字コードの話というよりもフォントの使用方法になってしまいますが、以下のサイトにMSX-Viewフォントの詳細が記されています。

http://www.yo.rim.or.jp/~anaka/AtoC/labo/view32.htm

----
余談ですが、MSX用漢字ROMの仕様は東芝が決めたらしい、という話があります。
個人的な事情により東芝のワープロ(Rupo)を分解し、フォントデータの入っていたROMの中身を覗いてみたことがあるのですが…グリフを構成するデータの並び順が異なるものの、グリフの並び順は同一でした。

http://www.uaa.org.uk/gomitext/2009/20091126/jw-r50f2_0303_alt.png (JW-R50F II)
http://www.uaa.org.uk/gomitext/2009/20091126/jw-r55f-0318_alt.png (JW-R55F)

RupoとMSXのどちらが先かは分かりませんが、ワープロで使われていそうな文字が混じっているのを見ると、この辺りに源があるのではないかという気がしています。
2009/11/30(月)20:33 |ささのたかよし | URL |編集
▲ページトップ

ありがとうございます。

第二水準にバグがあるとのことですが、第二水準の漢字の表示は正常に行なわれているのでしょうか?

> MSX用漢字ROMの仕様は東芝が決めたらしい、という話があります。
そう言えば、MSXのI/Oポートの仕様で、漢字ROMのところに「東芝仕様」とか書かれているのを見かけますね。
2009/12/01(火)10:23 |miraicorp | URL |編集
▲ページトップ

管面撮りはあまり得意では無いのですが…どうもバグっているようです。

手近にあったJISコード一覧表の、84区周辺を表示させてみました。

(MSX-View用フォントROMありの場合)
http://www.uaa.org.uk/gomitext/2009/20091202/imgp4008.jpg
(MSX-View用フォントROMなしの場合)
http://www.uaa.org.uk/gomitext/2009/20091202/imgp3983.jpg

この部分の調査だけで力尽きましたが、なんとなくこの状況からすると、他の区も問題がありそうな気がします。
2009/12/02(水)21:00 |ささのたかよし | URL |編集
▲ページトップ

ありがとうございます。

このバグった状態も一つの文字集合だとみなせば、変換処理で対応する必要が出て来るかもしれませんね。
2009/12/02(水)21:50 |miraicorp | URL |編集
▲ページトップ

コメントの投稿

FDAM7 と FPDAM8 ホーム gTef 0.16 beta 公開のお知らせ
トラックバック

この記事にトラックバックする(FC2ブログユーザー)
▲ページトップ

カレンダー

07 | 2017/08 | 09
- - 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 - -

プロフィール

miraicorp

Author:miraicorp
未来情報産業(株) 社長

主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。

twitterツイッター

管理用

検索フォーム

お知らせ

コメント等お気軽にどうぞ。

気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。

■お仕事を募集しております
ソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。
お気軽にご相談下さい

■初めての方へ
こまごまと更新しているため、他にも関連する記事があるかもしれません。
「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。
トップページはこちら

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

このブログをリンクに追加する

RSSリンクの表示

QRコード

QR